perm filename CLOOPS.MSG[COM,LSP]1 blob
sn#825123 filedate 1986-09-30 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00092 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00014 00002 ∂04-Sep-86 2153 Owners-CommonLoopsCore↑.pa@Xerox.COM Whoppers and run-super
C00036 00003 ∂04-Sep-86 2226 Owners-commonloopscore↑.pa@Xerox.COM Varia
C00042 00004 ∂05-Sep-86 1637 Bobrow.pa@Xerox.COM Re: Defmethod syntax proposal
C00047 00005 ∂05-Sep-86 1637 Owners-commonloopscore↑.pa@Xerox.COM Varia [what a useless subject!]
C00055 00006 ∂05-Sep-86 1637 Bobrow.pa@Xerox.COM Re: Message selection, continued
C00063 00007 ∂05-Sep-86 1638 Owners-commonloopscore↑.pa@Xerox.COM Re: Varia [what a useless subject!]
C00066 00008 ∂05-Sep-86 1836 Owners-CommonLoopsCore↑.PA@Xerox.COM Re: Defmethod syntax proposal
C00071 00009 ∂05-Sep-86 1836 Owners-commonloopscore↑.pa@Xerox.COM Terminology: instances
C00074 00010 ∂05-Sep-86 1902 Bobrow.pa@Xerox.COM [Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>:
C00097 00011 ∂05-Sep-86 1955 Owners-CommonLoopsCore↑.PA@Xerox.COM Methods Selected by Predications More General Than Classes
C00107 00012
C00108 00013 ∂08-Sep-86 1458 RPG Re: Defmethod syntax proposal
C00111 00014 ∂08-Sep-86 1500 RPG Re: Defmethod syntax proposal
C00116 00015 ∂08-Sep-86 1500 RPG Class versus Type System
C00122 00016 ∂08-Sep-86 1529 RPG Re: Methods Selected by Predications More General Than Classes
C00127 00017 ∂08-Sep-86 1533 RPG Class versus Type System
C00132 00018 ∂08-Sep-86 1535 RPG Generic Functions Defined by Defmethod
C00138 00019 ∂08-Sep-86 1537 RPG Re: Defmethod syntax proposal
C00142 00020 ∂08-Sep-86 1654 RPG Re: Defmethod syntax proposal
C00145 00021 ∂08-Sep-86 1654 RPG Generic Functions Defined by Defmethod
C00148 00022 ∂08-Sep-86 1727 RPG Re: Defmethod syntax proposal
C00152 00023 ∂08-Sep-86 1728 RPG Class versus Type System
C00157 00024 ∂09-Sep-86 2035 RPG Re: Subtypep
C00159 00025 ∂09-Sep-86 2244 RPG Re: Summary of features we all agree on
C00189 00026 ∂09-Sep-86 2244 RPG lack of word from the west coast
C00191 00027 ∂09-Sep-86 2324 RPG Class-of Versus Type-of
C00194 00028 ∂09-Sep-86 2336 RPG Things on which we agree
C00199 00029 ∂10-Sep-86 0837 RPG Re: [Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>:
C00202 00030 ∂10-Sep-86 0837 RPG Re: Subtypep
C00204 00031 ∂10-Sep-86 1730 RPG Getting together to work
C00206 00032 ∂11-Sep-86 1057 RPG Things on which we agree
C00215 00033 ∂11-Sep-86 1100 RPG Re: Things on which we agree
C00220 00034 ∂11-Sep-86 1103 RPG Re: Things on which we agree
C00225 00035 ∂11-Sep-86 1532 RPG Whoppers and Ontology
C00230 00036 ∂11-Sep-86 1610 RPG Re: Things on which we agree
C00236 00037 ∂12-Sep-86 0805 RPG specifying metaclass etc.
C00238 00038 ∂12-Sep-86 0812 RPG Re: Defmethod syntax proposal
C00245 00039 ∂12-Sep-86 1106 RPG Defmethod Syntax
C00249 00040 ∂12-Sep-86 1108 RPG Re: Defmethod syntax proposal
C00253 00041 ∂12-Sep-86 1245 RPG Re: Defmethod syntax proposal
C00262 00042 ∂12-Sep-86 1248 RPG Whoppers and Phenomenology
C00271 00043 ∂12-Sep-86 1545 RPG ordering of defclasses
C00275 00044 ∂12-Sep-86 1657 RPG Re: Defmethod syntax proposal
C00282 00045 ∂12-Sep-86 1752 RPG ordering of defclasses
C00286 00046 ∂12-Sep-86 1756 RPG Getting together to work
C00291 00047 ∂13-Sep-86 2051 RPG Defmethod syntax
C00301 00048 ∂13-Sep-86 2100 RPG abbreviated form of WITH
C00305 00049 ∂13-Sep-86 2101 RPG Re: Defmethod syntax
C00307 00050 ∂14-Sep-86 1112 Gregor.pa@Xerox.COM Re: Getting together to work
C00309 00051 ∂14-Sep-86 1118 Owners-CommonLoopsCore↑.pa@Xerox.COM Re: ordering of defclasses
C00312 00052 ∂14-Sep-86 1622 Gregor.pa@Xerox.COM Method Naming and Identity Proposal
C00314 00053 ∂14-Sep-86 1817 Gregor.pa@Xerox.COM default optional arguments to a generic function
C00320 00054 ∂14-Sep-86 1837 Owners-commonloopscore↑.pa@Xerox.COM Method Identification
C00322 00055 ∂15-Sep-86 1152 Owners-commonloopscore↑.pa@Xerox.COM Method Identification
C00325 00056 ∂15-Sep-86 1152 Owners-CommonLoopsCore↑.PA@Xerox.COM Re: Defmethod syntax
C00328 00057 ∂15-Sep-86 1152 Owners-CommonLoopsCore↑.PA@Xerox.COM Method Naming and Identity Proposal
C00333 00058 ∂15-Sep-86 1437 Owners-CommonLoopsCore↑.pa@Xerox.COM default optional arguments to a generic function
C00346 00059 ∂15-Sep-86 1436 Masinter.pa@Xerox.COM Re: Defmethod syntax
C00349 00060 ∂15-Sep-86 1436 Owners-commonloopscore↑.pa@Xerox.COM Goals of the Specification
C00352 00061 ∂15-Sep-86 1615 Owners-commonloopscore↑.pa@Xerox.COM Goals of the Specification
C00357 00062 ∂15-Sep-86 1743 Masinter.pa@Xerox.COM Re: Goals of the Specification
C00360 00063 ∂15-Sep-86 2005 Owners-CommonLoopsCore↑.PA@Xerox.COM Defmethod syntax
C00362 00064 ∂15-Sep-86 2101 Owners-CommonLoopsCore↑.pa@Xerox.COM default optional arguments to a generic function
C00373 00065 ∂16-Sep-86 0626 Owners-CommonLoopsCore↑.PA@Xerox.COM Proposed Goals (Statement for OOPSLA)
C00385 00066 /sub
C00397 00067 ∂16-Sep-86 0630 Owners-commonloopscore↑.pa@Xerox.COM Re: Goals of the Specification
C00401 00068 ∂16-Sep-86 1128 Owners-CommonLoopsCore↑.pa@Xerox.COM Re: default optional arguments to a generic function
C00406 00069 ∂16-Sep-86 1413 Gregor.pa@Xerox.COM the kinds of method lookup people claim they want
C00412 00070 ∂16-Sep-86 1841 Owners-CommonLoopsCore↑.pa@Xerox.COM run-super
C00428 00071 ∂16-Sep-86 1841 Owners-CommonLoopsCore↑.PA@Xerox.COM What we should agree on before OOPSLA
C00433 00072 ∂17-Sep-86 0856 Bobrow.pa@Xerox.COM Re: run-super
C00439 00073 ∂17-Sep-86 1036 Owners-CommonLoopsCore↑.pa@Xerox.COM Re: default optional arguments to a generic function
C00447 00074 ∂17-Sep-86 1037 Kahn.pa@Xerox.COM Re: run-super
C00450 00075 ∂17-Sep-86 1037 Kahn.pa@Xerox.COM DEFCLASS should replace DEFSTRUCT
C00454 00076 ∂17-Sep-86 1632 Gregor.pa@Xerox.COM Re: What we should agree on before OOPSLA
C00457 00077 ∂17-Sep-86 1636 Gregor.pa@Xerox.COM The name of WITH
C00458 00078 ∂17-Sep-86 1637 Owners-CommonLoopsCore↑.pa@Xerox.COM Re: Getting together to work
C00461 00079 ∂17-Sep-86 1636 Bobrow.pa@Xerox.COM Proposed Goals (Statement for OOPSLA)
C00473 00080 ∂17-Sep-86 1636 Owners-CommonLoopsCore↑.pa@Xerox.COM Re: default optional arguments to a generic function
C00490 00081 ∂17-Sep-86 1636 Owners-CommonLoopsCore↑.pa@Xerox.COM Re: run-super, whoppers, wrappers
C00508 00082 ∂17-Sep-86 1636 Gregor.pa@Xerox.COM required-xxx options to defclass
C00511 00083 ∂17-Sep-86 2028 Owners-CommonLoopsCore↑.pa@Xerox.COM DEFCLASS should replace DEFSTRUCT
C00514 00084 ∂17-Sep-86 2029 Owners-CommonLoopsCore↑.pa@Xerox.COM Re: run-super
C00519 00085 ∂17-Sep-86 2029 Masinter.pa@Xerox.COM Re: DEFCLASS should replace DEFSTRUCT
C00524 00086 ∂17-Sep-86 2031 Owners-CommonLoopsCore↑.pa@Xerox.COM Proposed Goals (Statement for OOPSLA)
C00528 00087 ∂17-Sep-86 2224 Owners-CommonLoopsCore↑.pa@Xerox.COM The name of WITH
C00530 00088 ∂17-Sep-86 2224 Owners-CommonLoopsCore↑.pa@Xerox.COM required-xxx options to defclass
C00533 00089 ∂18-Sep-86 0625 Owners-CommonLoopsCore↑.pa@Xerox.COM The name of WITH
C00536 00090 ∂18-Sep-86 0811 Owners-CommonLoopsCore↑.pa@Xerox.COM Proposed Goals (Statement for OOPSLA)
C00554 00091 ∂18-Sep-86 0900 Bobrow.pa@Xerox.COM Re: The name of WITH
C00560 00092 ∂18-Sep-86 0900 Bobrow.pa@Xerox.COM Re: DEFCLASS should replace DEFSTRUCT
C00563 ENDMK
C⊗;
∂04-Sep-86 2153 Owners-CommonLoopsCore↑.pa@Xerox.COM Whoppers and run-super
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 4 Sep 86 21:50:35 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 04 SEP 86 21:48:11 PDT
Return-Path: <Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.pa@XEROX.ARPA
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM ([192.10.41.41]) by
Xerox.COM ; 04 SEP 86 21:47:42 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 74741;
Fri 5-Sep-86 00:46:12 EDT
Date: Fri, 5 Sep 86 00:46 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Whoppers and run-super
To: CommonLoopsCore↑.pa@Xerox.COM
In-Reply-To: <860902-183338-1341@Xerox>
Message-ID: <860905004612.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 2 Sep 86 18:33 PDT
From: Bobrow.pa@Xerox.COM
Sorry about the slow response; I spent a lot of time thinking about this
instead of sending some sort of knee-jerk instant response.
There seems to be a lot in common between whoppers and the Loops use of
run-super. I have been trying to work out the appropriate relation
between run-super and daemon method combination with whoppers.
Whoppers are not expressible in the method combination language.
This is not completely true. They could easily be done in the method
combination language. We chose to do them instead as a separate layer
for the following reasons:
(1) We wanted the behavior of whoppers and wrappers to be constant,
independent of the method-combination type.
(2) We found that in old flavors having to worry about whoppers and
wrappers greatly complicated the definition of each method-combination
type. It seemed better to do it in a central place and get it out
of the way of the user who wants to define his own method combination.
(3) Whoppers and wrappers seem to us to be fundamentally different
from ordinary methods; in particular, they receive different arguments.
Wrappers, being macros, receive forms as arguments rather than receiving
the arguments of a generic function call. Less obviously, whoppers
receive different arguments; the continuation used by CONTINUE-WHOPPER
is passed to the whopper as two additional arguments that are added to
the lambda-list by defwhopper (never mind why it's two arguments instead
of one, that's a minor implementation detail.) There are efficiency
issues, discussed much later in this message, that make us wish to keep
whoppers separate from ordinary methods so as not to slow down ordinary
methods.
(4) I don't like :around methods for the irrelevant reason that Stallman's
flavor system has them and he misimplemented them in a way that appears
especially ugly to the user. Too much of the implementation mechanism
shows through.
None of these reasons is ineluctably compelling, and we could instead
have chosen to make DEFINE-METHOD-COMBINATION insert into the body a call
to a function to take care of the wrappers and whoppers, and then have
provided an option to turn this off and let the method-combination type
take direct control. I don't see a lot of benefit from this; what would
be accomplished by taking direct control other than surprising the user
by making wrappers and whoppers behave in an unexpected way? Maybe there
is something that I am not seeing.
Neither is run-super. I believe both could be fixed by adding a new
standard form corresponding to call-component-methods.
call-first-with-continuations <list-of-methods>
calls the first on the list, and makes available the list for the called
method. If run-super is invoked in the method, it does:
(call-first-with-continuations (cdr list-of-methods))
If continue-whopper we spell "run-super", and whopper as ":around", then
super-daemon method combination (allowing run-super in primary methods)
is defined by something like
(define-method-combination :super-daemon
((around "around" :every :base-flavor-last (:around))
(before "before" :every :base-flavor-last (:before))
(primary "primary" :every :base-flavor-last (:primary))
(after "after" :every :base-flavor-first (:after)))
(call-first-with-continuations
'(,. around
(multiple-value-prog2
(call-component-methods , before)
(call-first-with-continuations ',primary)
(call-component-methods ,after)))
This makes run-super be a feature of method-combination with
call-first-with-continuations only. It has the same model as it has in
Loops and Smalltalk, and computable at method-definition time.
Don't forget that continue-whopper allows changing the arguments that
are passed on to the continuation, whereas run-super does not. This can
be important sometimes. I think that's orthogonal to the rest of the
discussion, however.
I have not thought through a best implementation. An obvious one is to
bind the continuation list of functions in a special variable.
Does this make sense? It seems to provide a single coherent story.
There is no question that something along these lines, with the typos
and bugs taken out, could work. For example, the following code works
in New Flavors (more comments follow the code):
(DEFVAR *SUPERCLASS-CONTINUATIONS*)
(DEFUN RUN-SUPER ()
(FUNCALL (POP *SUPERCLASS-CONTINUATIONS*)))
(DEFUN CALL-FIRST-WITH-CONTINUATIONS (FORMS)
(IF (REST FORMS)
`(STACK-LET ((*SUPERCLASS-CONTINUATIONS*
(LIST ,@(MAPCAR (LAMBDA (FORM)
`(LAMBDA ()
(DECLARE (SYS:DOWNWARD-FUNCTION))
,FORM))
(REST FORMS)))))
,(FIRST FORMS))
(FIRST FORMS)))
(DEFINE-METHOD-COMBINATION :SUPER-DAEMON ()
((AROUND "around" :EVERY :MOST-SPECIFIC-FIRST (:AROUND))
(BEFORE "before" :EVERY :MOST-SPECIFIC-FIRST (:BEFORE))
(PRIMARY "primary" :EVERY :MOST-SPECIFIC-FIRST () :DEFAULT)
(AFTER "after" :EVERY :MOST-SPECIFIC-LAST (:AFTER)))
(CALL-FIRST-WITH-CONTINUATIONS
(NCONC (MAPCAR #'CALL-COMPONENT-METHOD AROUND)
`((MULTIPLE-VALUE-PROG2
,(CALL-COMPONENT-METHODS BEFORE)
,(CALL-FIRST-WITH-CONTINUATIONS
(MAPCAR #'CALL-COMPONENT-METHOD PRIMARY))
,(CALL-COMPONENT-METHODS AFTER))))))
(DEFGENERIC SDTEST (X Y)
(:METHOD-COMBINATION :SUPER-DAEMON))
(DEFFLAVOR SDTEST1 () ())
(DEFFLAVOR SDTEST2 () (SDTEST1))
(DEFFLAVOR SDTEST3 () (SDTEST2))
(DEFMETHOD (SDTEST SDTEST1) (X)
(LIST 1 X))
(DEFMETHOD (SDTEST SDTEST2) (X)
(DECLARE (IGNORE X))
(CONS 2 (RUN-SUPER)))
(DEFMETHOD (SDTEST SDTEST3) (X)
(DECLARE (IGNORE X))
(CONS 3 (RUN-SUPER)))
(DEFMETHOD (SDTEST SDTEST2 :AROUND) (X)
(LIST "[" (RUN-SUPER) "|" X "]"))
(SDTEST (MAKE-INSTANCE 'SDTEST3) 105)
; => ("[" (3 2 1 105) "|" 105 "]")
This implementation could use some additional error checking. More importantly,
it contains a serious bug. The dynamic scoping of *SUPERCLASS-CONTINUATIONS*
means that incorrect results can occur when closures from two different generic
function invocations are calling each other. To get correct operation, the
continuation must be lexically scoped. If this sounds esoteric, consider the
following example, which has been taken from a real-life program:
(defmethod print-object :around ((object italicized-object) stream)
(with-character-face (:italic stream)
(run-super))
which makes any object of class italicized-object print itself in italics.
With-character-face is just a macro that makes output to the given stream
appear in the given face while executing its body.
This looks fine until you expand the with-character-face macro, which
expands into [the following is simplified from what it actually expands
into in Genera]
(with-style-internal stream ':italic
(lambda (stream) (run-super)))
where with-style-internal is a generic function handled by
a stream method that sets up for italic characters and calls
back into the lambda. If the handling of with-style-internal
also involves :around methods, *SUPERCLASS-CONTINUATIONS* will
be bound and the run-super inside the lambda will call a
with-style-internal method instead of a print-object method.
No good.
Lexically scoping the continuation is possible in New Flavors also.
An extra argument has to be inserted into the arglist of any method
that uses run-super, to receive the continuation, since it can no
longer be passed behind the lambda-list's back in a special variable,
and this code transformation makes everything a little more complicated.
Here is the working, tested code (more comments after the code):
(DEFUN RUN-SUPER ()
(ERROR "RUN-SUPER not called from a proper lexical environment."))
;;; Call a method, passing the continuation before the regular arguments
(DEFUN CALL-COMPONENT-METHOD-WITH-CONTINUATION (METHOD CONTINUATION-FORM ARGS)
(CALL-COMPONENT-METHOD METHOD
:ARGLIST (LIST `(LAMBDA ()
(DECLARE (SYS:DOWNWARD-FUNCTION))
,CONTINUATION-FORM)
ARGS)
:APPLY T))
;;; Call a sequence of methods, each with a continuation that calls the next
;;; method. The continuation of the last method is the second argument.
(DEFUN CALL-COMPONENT-METHODS-WITH-CONTINUATION (METHODS CONTINUATION-FORM ARGS)
(IF METHODS
(CALL-COMPONENT-METHOD-WITH-CONTINUATION
(FIRST METHODS)
(CALL-COMPONENT-METHODS-WITH-CONTINUATION
(REST METHODS) CONTINUATION-FORM ARGS)
ARGS)
CONTINUATION-FORM))
(DEFINE-METHOD-COMBINATION :SUPER-DAEMON-2 ()
((AROUND "around" :EVERY :MOST-SPECIFIC-FIRST (:AROUND))
(BEFORE "before" :EVERY :MOST-SPECIFIC-FIRST (:BEFORE))
(PRIMARY "primary" :EVERY :MOST-SPECIFIC-FIRST () :DEFAULT)
(AFTER "after" :EVERY :MOST-SPECIFIC-LAST (:AFTER)))
(:METHOD-TRANSFORMER
;; Insert continuation argument into methods that can call RUN-SUPER
(:METHOD-ARGLIST
(IF (MEMBER (METHOD-OPTIONS FUNCTION-SPEC)
'((:AROUND) () (:DEFAULT))
:TEST #'EQUAL)
(CONS 'RUN-SUPER-CONTINUATION METHOD-ARGLIST)
METHOD-ARGLIST))
;; Change arglist used for error-checking correspondingly
(:GENERIC-METHOD-ARGLIST
(IF (MEMBER (METHOD-OPTIONS FUNCTION-SPEC)
'((:AROUND) () (:DEFAULT))
:TEST #'EQUAL)
(LIST* (FIRST GENERIC-METHOD-ARGLIST)
'RUN-SUPER-CONTINUATION
(REST GENERIC-METHOD-ARGLIST))
GENERIC-METHOD-ARGLIST))
;; Define RUN-SUPER macro locally in the body of such methods
(:METHOD-BODY
(IF (MEMBER (METHOD-OPTIONS FUNCTION-SPEC)
'((:AROUND) () (:DEFAULT))
:TEST #'EQUAL)
(MULTIPLE-VALUE-BIND (DECLARATIONS BODY)
(SI:FIND-BODY-DECLARATIONS METHOD-BODY NIL)
`(,@DECLARATIONS
(IGNORE RUN-SUPER-CONTINUATION)
(MACROLET ((RUN-SUPER ()
`(FUNCALL RUN-SUPER-CONTINUATION)))
,@BODY)))
METHOD-BODY)))
(:ARGLIST IGNORE &REST ARGS)
(CALL-COMPONENT-METHODS-WITH-CONTINUATION
AROUND
`(MULTIPLE-VALUE-PROG2
,(CALL-COMPONENT-METHODS BEFORE)
,(CALL-COMPONENT-METHODS-WITH-CONTINUATION
PRIMARY
`(ERROR "RUN-SUPER past the least-specific method")
ARGS)
,(CALL-COMPONENT-METHODS AFTER))
ARGS))
(DEFGENERIC SDTEST-2 (X Y)
(:METHOD-COMBINATION :SUPER-DAEMON-2))
(DEFFLAVOR SDTEST1 () ())
(DEFFLAVOR SDTEST2 () (SDTEST1))
(DEFFLAVOR SDTEST3 () (SDTEST2))
(DEFMETHOD (SDTEST-2 SDTEST1) (X)
(LIST 1 X))
(DEFMETHOD (SDTEST-2 SDTEST2) (X)
(DECLARE (IGNORE X))
(CONS 2 (RUN-SUPER)))
(DEFMETHOD (SDTEST-2 SDTEST3) (X)
(DECLARE (IGNORE X))
(CONS 3.0 (RUN-SUPER)))
(DEFMETHOD (SDTEST-2 SDTEST2 :AROUND) (X)
(LIST "[" (RUN-SUPER) "|" X "]"))
(SDTEST-2 (MAKE-INSTANCE 'SDTEST3) 105)
; => ("[" (3.0 2 1 105) "|" 105 "]")
I wouldn't want to make either of these the default, because of the
efficiency cost of all this extra mechanism. This is based on my
prejudice that "normal" programs won't use run-super and shouldn't have
to pay the cost of keeping around the information needed for run-super
to work. With modest amounts of additional hair in the
:method-transformer, it should be possible to scan the body of the
method for calls to run-super, and generate different code if it is not
present. It's midnight, though, so I'm going to stop here.
In conclusion: yes, it's possible to do run-super this way, and
presumably it works about as well as any other way of doing run-super.
Yes, it's possible to do whoppers this way, and they work about as well
as any other way of doing whoppers. You can't do wrappers exactly this
way, since they are macros rather than functions, but there is certainly
no inherent reason that code for wrappers couldn't be written into a
define-method-combination, too. The big difference between doing these
things this way and doing them the way New Flavors does it now is
primarily that the expensive continuation-passing mechanisms needed to
make whoppers/run-super work are invoked explicitly by using a different
special form to define a whopper than to define a method, instead of
implicitly by calling run-super somewhere in the body of the method, and
secondarily that the hair for wrappers and whoppers is kept hidden from
the user who just wants to define a new type of method-combination
without having to worry about anything complicated.
∂04-Sep-86 2226 Owners-commonloopscore↑.pa@Xerox.COM Varia
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 4 Sep 86 22:26:27 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 04 SEP 86 22:25:31 PDT
Return-Path: <RPG@SAIL.STANFORD.EDU>
Redistributed: commonloopscore↑.pa
Received: from SAIL.STANFORD.EDU (SU-AI.ARPA) by Xerox.COM ; 04 SEP 86
22:25:18 PDT
Date: 04 Sep 86 22:25 PDT
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Subject: Varia
To: commonloopscore↑.pa@Xerox.COM
Message-ID: <860904-222531-1191@Xerox>
We want to distinguish the type hierarchy from the class lattice.
Therefore, in messages where I say `argument specifier,' I am
not, as Moon suggests, making a typo for `type specifier.'
`Instance of a class' is different from `instance of a flavor' or
`instance of a defstruct.' We've made a parallel class lattice
corresponding to the type hierarchy in CLtL. We decided (today) to flush
ATOM and COMMON from that lattice (vector is an atom). Therefore, a cons
cell is an instance of the CONS class. Because the metaclass of a CONS
cell is not the class CLASS (but is BUILT-IN-CLASS or some such) its
interpretation as an instance is different from that of an instance
meta-class is CLASS. Everything in Common Lisp is an instance of some
class.
Danny and I go around daily on the disposition of method selection.
We now have yet another proposal for it. In this one this example
does what DLW expects:
(let ((*standard-output* <instance of hairy-display-hardware>))
(print foo))
Because the generic function PRINT has as function parameters:
(object &optional (stream *standard-output*))
Defmethods cannot default unsupplied arguments. Danny's message will
present this new version. (I'm too burned to do it.)
I'm fresh enough, though, to present why I don't like defmethods
creating generic functions. In my view, a generic function is
something that responds T to (typep <gf> 'function). It has other
information within itself. It has no name but can be associated with
a name, just as in
(defun foo (x) ...)
the thing in the symbol-function cell has no name but is associated with
the name `FOO.' The parts of the generic function are the discriminating
function, the methods, the function parameters, various class pointers,
and etc. Usually the methods are stored as part of the method object.
Defmethod adds another method to a generic function. That is, it adds a
new subpart to an existing thing. It seems odd to me that adding a new
subpart should create the thing of which it is to become a part. There is
a dimension whose extremity is absolute insanity, and the current proposal
to allow defmethod to create the superpart has a non-zero component of that
dimension. An example of the insanity at the extreme in this dimension is
a possible proposal that
(setf (car x) 7)
does this
(progn
(unless (and (boundp 'x) (typep x 'cons)) (setq x (cons () ())))
(setf (car x) 7))
(Note that Lisp/VM does the equivalent of this
(setf (symbol-value <symbol>) <symbol>)
when the symbol <symbol> is interned.)
I grant we are not very far down this dimension, but why head that way?
I will be away until monday, so enjoy.
-rpg-
∂05-Sep-86 1637 Bobrow.pa@Xerox.COM Re: Defmethod syntax proposal
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Sep 86 16:36:53 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 SEP 86 14:49:56 PDT
Date: 5 Sep 86 10:52 PDT
From: Bobrow.pa@Xerox.COM
Subject: Re: Defmethod syntax proposal
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Thu, 4 Sep 86 18:01 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CommonLoopsCore↑.PA@Xerox.COM
Message-ID: <860905-144956-1108@Xerox>
Will (defmethod generic option... lambda-list body...) be okay with
you,
or do we need to keep searching for a suitable syntax? A more real
example of the syntax would be
(defmethod turn-off-valve :before ((v master-valve))
(unless (check-with-safety-engineer v 'off)
(unsafe-operator-action "Don't do that! It will explode")))
Since all the options for method combination are either keywords or
numbers and type is not, one can distinguish the cases.
If this is not the case,
we could insist that there always be such a keyword to start.
They aren't keywords. You got fooled by looking at existing examples
where
by coincidence they were always keywords, but in general it's not
going to
work to restrict the options attached to a method to be always
keywords.
There are applications where these are names of things and the names
can
be any symbol (I think we can safely exclude nil, I hope I'm not
wrong).
Will (defmethod generic option... lambda-list body...) be okay with
you,
or do we need to keep searching for a suitable syntax?
I don't like having to put an additional item between the generic name
and the lambda-list, especially since I expect most methods to not have
any options declaration.
An alternative syntaxsuggestion:
(defmethod name-or-name-and-options lambda-list ...)
where
name-or-name-and-options = name|
(name :combination {combine-options}*)|
(name class-name {combine-options}*)
This makes it somewhat more difficult for CommonLoops type users to use
method combination. Alternatively, Flavors type use could be made
slightly more difficult by using
name-or-name-and-options = name|
(name {combine-options}*)|
(name (:class class-name) {combine-options}*)
I prefer the latter. Method combination code could process the
(:class class-name) option and change the method definition as
specified by you.
An arguments for the former is to preserve old Flavors code.
-- danny
∂05-Sep-86 1637 Owners-commonloopscore↑.pa@Xerox.COM Varia [what a useless subject!]
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Sep 86 16:37:19 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 SEP 86 14:53:05 PDT
Return-Path: <Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM>
Redistributed: commonloopscore↑.pa@XEROX.ARPA
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM ([192.10.41.41]) by
Xerox.COM ; 05 SEP 86 14:46:41 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 75195;
Fri 5-Sep-86 16:24:21 EDT
Date: Fri, 5 Sep 86 16:24 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Varia [what a useless subject!]
To: commonloopscore↑.pa@Xerox.COM
In-Reply-To: <860904-222531-1191@Xerox>
Message-ID: <860905162420.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 04 Sep 86 22:25 PDT
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
We want to distinguish the type hierarchy from the class lattice.
I thought one of the big points of this whole affair was to do just
the opposite, i.e. to unify the type lattice and the class lattice.
Therefore, in messages where I say `argument specifier,' I am
not, as Moon suggests, making a typo for `type specifier.'
`Instance of a class' is different from `instance of a flavor' or
`instance of a defstruct.' We've made a parallel class lattice
corresponding to the type hierarchy in CLtL. We decided (today) to flush
ATOM and COMMON from that lattice (vector is an atom). Therefore, a cons
cell is an instance of the CONS class. Because the metaclass of a CONS
cell is not the class CLASS (but is BUILT-IN-CLASS or some such) its
interpretation as an instance is different from that of an instance
meta-class is CLASS. Everything in Common Lisp is an instance of some
class.
Fine, but this doesn't seem to address the terminological dilemma I was
asking about. What do we call the objects that aren't primitive, when we
need to distinguish them from the object that are primitive?
Danny and I go around daily on the disposition of method selection.
I've noticed.
We now have yet another proposal for it. In this one this example
does what DLW expects:
(let ((*standard-output* <instance of hairy-display-hardware>))
(print foo))
Because the generic function PRINT has as function parameters:
(object &optional (stream *standard-output*))
Defmethods cannot default unsupplied arguments. Danny's message will
present this new version. (I'm too burned to do it.)
I look forward to seeing it.
I'm fresh enough, though, to present why I don't like defmethods
creating generic functions. In my view, a generic function is
something that responds T to (typep <gf> 'function). It has other
information within itself. It has no name but can be associated with
a name, just as in
(defun foo (x) ...)
the thing in the symbol-function cell has no name but is associated with
the name `FOO.' The parts of the generic function are the discriminating
function, the methods, the function parameters, various class pointers,
and etc. Usually the methods are stored as part of the method object.
Defmethod adds another method to a generic function. That is, it adds a
new subpart to an existing thing. It seems odd to me that adding a new
subpart should create the thing of which it is to become a part. There is
a dimension whose extremity is absolute insanity, and the current proposal
to allow defmethod to create the superpart has a non-zero component of that
dimension. An example of the insanity at the extreme in this dimension is
a possible proposal that
(setf (car x) 7)
does this
(progn
(unless (and (boundp 'x) (typep x 'cons)) (setq x (cons () ())))
(setf (car x) 7))
(Note that Lisp/VM does the equivalent of this
(setf (symbol-value <symbol>) <symbol>)
when the symbol <symbol> is interned.)
I grant we are not very far down this dimension, but why head that way?
I understand everything you said above, but none of this talk about
implementation addresses my point, which was concerned with the concepts
that the user thinks about. Thinking about the implementation first is
not a good way to design something that is easy to use and to
understand, in my opinion.
∂05-Sep-86 1637 Bobrow.pa@Xerox.COM Re: Message selection, continued
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Sep 86 16:37:31 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 SEP 86 15:56:41 PDT
Date: 5 Sep 86 15:56 PDT
From: Bobrow.pa@Xerox.COM
Subject: Re: Message selection, continued
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Thu, 4 Sep 86 16:15 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CommonLoopsCore↑.PA@Xerox.COM
Message-ID: <860905-155641-1385@Xerox>
May I assume that everywhere you say "argument specifier" this is a
typo
for "type specifier"? Or are you really introducing a new term here?
Yes "argument specifier" is more general term than type specifier or
class specifier. It can specify, for example, that the argument must
match a particular individual. Any extensions people want to make about
specification of arguments would go here.
In yesterday's round with Gabriel and Co. we came up with the following
proposed new set of rules for message selection.
1) All uses of defmethod must be preceded by a defgeneric (but see
discussion *1 below), and the defgeneric and the defmethods must all
have congruent lambda-lists. defmethods can provide argument-specifiers
on optional arguments (but see 6 below).
2) Defgeneric can have an arbitrary lambda-list.
3) All default values for optional arguments are provided computed from
forms in the defgeneric.
4) When a generic function is called, it computes and fills in values
for any unsupplied arguments.
5) Discrimination is done on the basis of all provided and filled
values. All methods of the generic function that match are considered.
The most specific method is chosen (rules not given here).
All provided and filled in values are passed to the method.
6) Since defmethod argument list cannot have default value forms for
optionals, we make the syntax for defmethod lambda-list be:
defmethod-lambda-list:= ({required-arg}* [&optional {optional-arg}*])
optional-arg:=
var-name|
(var-name arg-specifier)
(var-name arg-specifier supplied-p-name)
The third form is provided to allow a user to supply a local name for
the supplied-p. This supplied-p is computed by the generic function, and
passed in to the method. It can then be used locally to allow the
program to override the default value provided from defgeneric. If only
a supplied-p-name is wanted, he arg-specifier T can be used to match any
argument.
*1) RPG and DLW (I believe) support the minimalist position of insisting
that the user always write the defgeneric themselves, and have it
evaluated before the defmethod. There are several increasingly
DWIM-like positions that back away from this stricture by allowing
defmethod to call defgeneric if no generic function exists.
a) If the defmethod specifies no optional arguments, then a defgenric
form is invoked with the stripped lambda list.
b) Allow the defmethod to specify optional arguments as above, and
create a stripped lambda list for the constructed defgeneric that has
only var-names for the optional arguments; that is, NIL will be provided
for the values of the optional arguments. The supplied-p portion of the
optional-arg apecification allows internal resetting of the value of the
arg if desired. If default values other than NIL are wanted, a
defgeneric form must be used.
c) Return to our previous syntax of defmethod, with
optional-arg:=
var-name|
(var-name [default-value-form [supplied-p-name]])
((var-name arg-specifier) [default-value-form [supplied-p-name]])
Construct a defgeneric from the defmethod simply stripping out the
arg-specifiers. An error is signalled if any defmethod has a
default-value-form not equal to the one found in the defgeneric. This
provides a syntactic rather than a semantic check on identity of default
values, as proposed by Moon. Again, as opposed to Moon's suggestion,
the default-values are all computed in the discriminating function, and
passed to the methods. supplied-p parameters can also be passed to the
methods from the generic function.
Proposal c also implies that every method must contain the same default
value forms, which violates some modularity. A possible fix for this is
reinterpret the naked var-name to mean unspecified default-value, or to
specify a funny value :no-default-form that can be used in that place
for optionals.
I like either (b) or (c). An argument for (c) given to me by Ken Kahn
is that users should move from defun to defmethod as a standard way to
program, even when not providing any argument specifiers. This means
that all their functions are specializable. This implies allowing a
defmethod syntax that is identical to defun, with no preceding
declaration.
-- danny
∂05-Sep-86 1638 Owners-commonloopscore↑.pa@Xerox.COM Re: Varia [what a useless subject!]
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Sep 86 16:37:48 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 SEP 86 16:14:38 PDT
Redistributed: commonloopscore↑.pa
Received: from Cabernet.ms by ArpaGateway.ms ; 05 SEP 86 16:13:56 PDT
Date: 5 Sep 86 16:12 PDT
From: Bobrow.pa@Xerox.COM
Subject: Re: Varia [what a useless subject!]
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Fri, 5 Sep 86 16:24 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: commonloopscore↑.pa@Xerox.COM
Message-ID: <860905-161438-1438@Xerox>
We want to distinguish the type hierarchy from the class lattice.
I thought one of the big points of this whole affair was to do just
the opposite, i.e. to unify the type lattice and the class lattice.
Right. RPG was just misguided. The Common Lisp type lattice is mapped
into the class lattice. Missing from the class lattice are uses of the
type system that are really predications. In this category we put the
type atom = (SATISFIES (NOT (CONSP X))
and common (a non-inherited feature) = (SATISFIES (MEMQ X '(CONS ...))
Why do you want to distinguish "primitive" instances from non-primitive
ones. I thought of the ugly term "non-slotted instances". Numbers have
no slots. But one can create objects with no slots using defclass. One
can also think of CONS cells as having two slots with accessors car and
cdr. Is there any thing we need to say about these items aside from
their history as Common Lisp types?
-- danny
∂05-Sep-86 1836 Owners-CommonLoopsCore↑.PA@Xerox.COM Re: Defmethod syntax proposal
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Sep 86 18:36:12 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 SEP 86 17:57:09 PDT
Return-Path: <Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.PA@XEROX.ARPA
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM ([192.10.41.41]) by
Xerox.COM ; 05 SEP 86 17:52:25 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 75306;
Fri 5-Sep-86 20:51:17 EDT
Date: Fri, 5 Sep 86 20:51 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Defmethod syntax proposal
To: CommonLoopsCore↑.PA@Xerox.COM
In-Reply-To: <860905-144956-1108@Xerox>
Message-ID: <860905205118.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 5 Sep 86 10:52 PDT
From: Bobrow.pa@Xerox.COM
Will (defmethod generic option... lambda-list body...) be okay with you,
or do we need to keep searching for a suitable syntax?
I don't like having to put an additional item between the generic name
and the lambda-list, especially since I expect most methods to not have
any options declaration.
I think my syntax description was not clear enough. I am not proposing
that there be anything between the generic name and the lambda-list when
no options are specified. Let me give some more examples (just the
first line of each):
(defmethod turn-off-valve ((v valve))
(defmethod turn-off-valve :before ((v master-valve))
(defmethod great-scott piece environmental-impact ((x foo) (y bar))
(defmethod (turn-off-valve valve) ()
(defmethod (turn-off-valve master-valve :before) ()
(defmethod (great-scott foo piece environmental-impact) ((y bar))
An alternative syntaxsuggestion:
(defmethod name-or-name-and-options lambda-list ...)
where
name-or-name-and-options = name|
(name :combination {combine-options}*)|
(name class-name {combine-options}*)
or
name-or-name-and-options = name|
(name {combine-options}*)|
(name (:class class-name) {combine-options}*)
I prefer the latter.
Neither of these turns me on. I think whichever one involves the
"extra" word (:combination or :class) is going to discourage users
from using that style. I would rather either use the syntax
exemplified above or use different macros for defining classical
methods and general methods.
An argument for the former is to preserve old Flavors code.
Yes, one criterion I would like to preserve is that a mechanical
translation program can look at a piece of source text and reliably
classify it into CommonLoops, Flavors, or the new Common Lisp standard.
Mechanical translation tools work more smoothly for users if they
operate correctly on their own output; this makes incremental conversion
of programs a lot easier.
∂05-Sep-86 1836 Owners-commonloopscore↑.pa@Xerox.COM Terminology: instances
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Sep 86 18:36:35 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 SEP 86 17:58:00 PDT
Return-Path: <Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM>
Redistributed: commonloopscore↑.pa@XEROX.ARPA
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM ([192.10.41.41]) by
Xerox.COM ; 05 SEP 86 17:57:20 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 75307;
Fri 5-Sep-86 20:56:10 EDT
Date: Fri, 5 Sep 86 20:56 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Terminology: instances
To: commonloopscore↑.pa@Xerox.COM
In-Reply-To: <860905-161438-1438@Xerox>
Message-ID: <860905205611.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 5 Sep 86 16:12 PDT
From: Bobrow.pa@Xerox.COM
Why do you want to distinguish "primitive" instances from non-primitive
ones. I thought of the ugly term "non-slotted instances". Numbers have
no slots. But one can create objects with no slots using defclass. One
can also think of CONS cells as having two slots with accessors car and
cdr. Is there any thing we need to say about these items aside from
their history as Common Lisp types?
See the discussion on 2-3 September about the awkwardness in Sonya's glossary
that resulted from trying to avoid making this distinction.
∂05-Sep-86 1902 Bobrow.pa@Xerox.COM [Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>:
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Sep 86 19:01:42 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 SEP 86 18:49:12 PDT
Date: 5 Sep 86 18:49 PDT
From: Bobrow.pa@Xerox.COM
Subject: [Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>:
Summary of features we all agree on ]
To: CommonLoopsCore↑.PA@Xerox.COM
cc: Bobrow.pa@Xerox.COM
Message-ID: <860905-184912-1633@Xerox>
Part I describes the basic tools for defining classes, methods,
generic
functions, and method combination types, and for making instances
of
classes.
DEFINING CLASSES
(DEFCLASS class-name (slot-spec...) (super-class-name...)
option...)
Not quite. We have the opposite order for (super-class-name...) and
(slot-spec...).
(DEFCLASS class-name (super-class-name...) (slot-spec...) option...)
class-name is a non-null symbol that names the class being defined.
If a
class is already defined with this name, this definition replaces
the
old definition. The default meta-class ensures that when the
definition of
aclass changes, each existing instance of the class is updated to
the new
format the next time it is accessed.
Each slot-spec is one of:
slot-name a non-null symbol.
(slot-name initial-value-form)
(slot-name slot-option...)
Each slot-option is an option name followed by its value.
The defined slot-options and their arguments are:
= initial-value-form
This an alternate way for providing a default initial
value form.
How is this form distinguished from the previous. By having more than
two elements??? How do you not give an init value form.
:accessor generic-function-name
Specifies that a function named
generic-function-name
be automatically generated, to read the value of
this
slot. SETF may be used with generic-function name
to
write the value of the slot.
OK. If generic-function-name is NIL then this is a NOOP. Specified so
programs can generate these.
:reader generic-function-name
Specifies that a function named
generic-function-name
be automatically generated, to read the value of
this
slot.
We have called this :read-accessor. We specify that if this is given,
then SETF may NOT be used with this accessor. If generic-function-name
is NIL then this is a NOOP.
:initable keyword
Specifies a keyword to be used to specify an
initial
value of this slot, when a new instance is being
made.
I think this is OK. Should allow value of NIL. Default is T
:allocation
:allocation can have values
:instance (allocated in the instance),
:class (storage allocated in the class and shared by all instances),
:dynamic (storage allocated in the instance on first use
(like Flavors Proplist mixin)
:none expect accessor methods for this to be defined for this slot
in this class
:initialize-only flag
If flag = T, then this slot cannot be changed after initialization (a
better name for :read-only). flag=T implies no accessors are generated.
default is NIL.
If no initial value is specified either in the DEFCLASS or the MAKE
form,
the initial value of the slot is undefined and it is an error to
reference
it. This is the same behavior as a DEFVAR with no
initial-value-form.
We hate these "it is an error" statements. We haven't discussed this
particular issue.
Each super-class-name is a non-null symbol.
Each option is one of:
option-name
(option-name argument...)
Each option-name is a keyword that names an option; the arguments
depend
on
the option.
OK
The set of defined options and their arguments is:
(:accessor-prefix prefix slot-name...)
(:reader-prefix prefix slot-name...)
(:default-init-plist keyword-argument...)
(:initable-slots slot-name...)
(:init-keywords keyword...)
The only one of these that we have agreed to is:
(:accessors-with-prefix string-or-symbol)
which causes accessors to be generated with the given prefix for ALL
slots that do not have local specification of any of :accessor,
:read-accessor, or :initialize-only. If this form does not appear, then
no accessors for slots are generated.
Note they we have made this be a single default that applies uniformly.
No specific slots can be mentioned, and this option can appear only
once. The arguments for this way of doing business are:
1) Anything not uniform is local to a slot description
2) There are no redundant, possibly inconsistent, declarations
(:documentation string)
OK
(:meta-class class-name)
No, we think this should be done using the meta-object protocol, since
the parsing of the defclass is not under the control of the meta-class.
However, I think we could be convinced otherwise.
(:required-classes class-name...)
(:required-init-keywords keyword...)
(:required-slots slot-name...)
(:required-methods generic-function-name...)
No. These seem like environmental features, and should not be part of
the spec. We should make some comment about how additional options may
be supported by the standard class in particular implementations, and
ones not understood will either be ignored, or have warnings issued.
(:constructor function-name lambda-list)
We have allowed the full generality of the defstruct syntax for this
one. Do you think it should be restricted to this boa-constructor
For the :ACCESSOR-PREFIX, :READER-PREFIX, and :INITABLE-SLOTS
options,
you can omit slot-names to indicate that the option applies for all
slots of
this class.
See above
It is legal to specify more than one accessor and reader for a
single
slot.
We argued about this, and decided we didn't like it. Why is it good?
DEFINING METHODS AND SETF METHODS
The general syntax for defining a method is:
(DEFMETHOD generic-function-name method-option...
method-lambda-list
body...)
No. See my earlier message.
(DEFMETHOD name-and-options
method-lambda-list
body...)
generic-function-name is a non-null symbol.
name-and-options is a non-null symbol or (name . method-options)
See my earlier message.
Each method-option is a non-null atom that describes the type of
this
method. Some examples of method-options are: :BEFORE and :AFTER.
method-lambda-list is a lambda-list with one difference. Where a
lambda-list allows only a variable and not a list, a
type-qualified-
variable may be used. However, type-qualified-variables cannot be
used
for
&aux variables, supplied-p parameters, or &rest parameters. A
type-qualified-variable is a list such as: (variable-name
type-specifier).
Note that the use of &optional is still under discussion.
type-specifier ---tbd---
type-specifer and its uses should be replaced by argument-specifier.
This will include class-names (class-specifiers) and individuals. The
meaning of argument-specifier may be extended by users who build their
own discriminators.
For convenience in defining a classical method, the following
syntax is
provided:
(DEFMETHOD (generic-function-name first-arg-type method-option...)
method-lambda-list
body...)
The classical syntax is equivalent to the following expression in
the
general syntax:
(DEFMETHOD generic-function-name method-option...
((self first-type-arg) method-lambda-list...)
(with (self)
body...))
See other message
The general syntax for defining a SETF method is:
(DEFMETHOD-SETF generic-function-name method-option...
method-lambda-list setf-lambda-list
body...)
The classical syntax for defining a SETF method is:
(DEFMETHOD-SETF (generic-function-name first-arg-type
method-option...)
method-lambda-list setf-lambda-list
body...)
generic-function-name and method-option are the same as for
DEFMETHOD.
setf-lambda-list is a lambda-list containing exactly one required
parameter, which may be type-qualified. In other words,
setf-lambda-list
is one of:
(variable-name)
((variable-name type-specifier))
Same problem with this syntax. But we agree that DEFMETHOD-SETF is a
better name. If you liked my other syntax suggestions, then this one
follows. Again type-specifier -> argument-specifier. Are we not
allowing multiple values to be stored. In the silver book it talks
about extensions to the corresponding list of store variables. I have
no problem with the restriction.
DEFINING GENERIC FUNCTIONS
(DEFGENERIC generic-function-name lambda-list option...)
(DEFGENERIC-SETF generic-function-name lambda-list setf-lambda-list
option.
generic-function-name is a non-null symbol.
lambda-list is an ordinary lambda-list except no &aux variables are
allowed.
setf-lambda-list is (variable-name).
Yes, except that we allow a documentation string before the options.
What do you think???
Each option is one of:
option-name
(option-name argument...)
Each option-name is a keyword that names an option; the arguments
depend
on the option.
OK
The set of defined options and their arguments is:
[--Should declarations and doc strings be allowed?--]
(:documentation string)
See above.
(:optimize spec...)
Is this for all methods, or just the discriminating function. This seems
weird to me
(:method-combination name argument...)
What is the argument in this form?
(:generic-function-class class-name)
(:method-class class-name)
(:order parameter-name...)
We have been using :dispatch-order for the keyword :order. It should
really be
:argument-precedence-order.
[more?]
Additional options should be allowed, as in defclass.
WITH
We have agreed that WITH should exist, but we haven't decided
anything
more specific about it yet.
Right; we haven't decided anything yet. There are two different
proposals under discussion. One turns names in calls on the accessors
(we call that one WITH). The other turns them into primitive slot
accesses (we call that one %WITH).
DEFINING NEW TYPES OF METHOD COMBINATION
(DEFINE-SIMPLE-METHOD-COMBINATION name operator-name
[single-arg-is-value]
[pretty-name])
This function defines a new type of method combination in which all
the
methods are called and their values are passed to the operator
specified
by
operator-name.
name is a non-null symbol, often a keyword, that is the name of the
type
of method combination being defined.
operator-name can be a symbol or a lambda-expression,
the name of a function, a macro, or a special form.
single-arg-is-value is t or nil; by default it is nil.
pretty-name is a string. It defaults to the lower case version of
the
supplied name.
We haven't agreed to this at all yet. super-daemon method combination
we believe in. But this simple case seems strange to me, and if it can
be defined with the stronger DEFINE-METHOD-COMBINATION, then let's not
put it in the spec.
I didn't see whoppers described in daemon combination section of the
Flavors manual -- at least not in the early section. Does this mean
that it is not a feature of daemon combination?
We believe that at least on the west coast, run-super will be used much
more than daemon combination. Hence my attempt to unify them. An
answer to Moons answer next week.
(DEFINE-METHOD-COMBINATION method-combination-type-name
lambda-list
(method-pattern...) option... body...)
This function behaves the same way as in Flavors. See the Flavors
documentation for details.
We believe that a simple version of this should be in the spec. I don't
know yet what simple means. At least powerful enough to define the
extended features, but not including the full library of standardly
available combinations types.
Making a New Instance
(MAKE class-name keyword-argument...)
MAKE is the function that makes and initializes an instance of a
class.
The allowed keyword-arguments depend on the DEFCLASS form. Any
keyword
specified with the :INITABLE, :INITABLE-SLOTS, or :INIT-KEYWORDS
option
is allowed.
If a keyword-argument is given to MAKE, it overrides any default
that is
given in the DEFCLASS form, such as the :DEFAULT-INIT-PLIST option,
or
the initial-value-form syntax.
Modulo isssues on keywords and specification of initable, this is
basically correct.
OTHER FUNCTIONS
Other functions of interest to the general programmer [---tbd---].
This list came from the 8 August meeting; it can serve as a
starting
agenda
for this section:
find-flavor / class-named
Yes class-named
typep
classp is the right name
type-of
class-of
Yes on class-of
operation-handled-p ??
Something like this is needed
remove-class
remove-method
change-class
Yes
-- danny
∂05-Sep-86 1955 Owners-CommonLoopsCore↑.PA@Xerox.COM Methods Selected by Predications More General Than Classes
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Sep 86 19:55:26 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 SEP 86 19:53:35 PDT
Return-Path: <Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.PA@XEROX.ARPA
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM ([192.10.41.41]) by
Xerox.COM ; 05 SEP 86 19:53:11 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 75331;
Fri 5-Sep-86 22:52:05 EDT
Date: Fri, 5 Sep 86 22:52 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Methods Selected by Predications More General Than Classes
To: CommonLoopsCore↑.PA@Xerox.COM
Message-ID: <860905225205.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
The following message appears to have been lost in the network.
At least, it's not in the archive, and Danny's messages indicate
that he obviously hasn't read it. Maybe what really happened is
that I forgot to send it, but just edited it into my own file.
In any case, here it is.
CommonLoops allows method selection by classes and by one kind of
predication, equality to a constant (EQL, I presume). If we're going to
go more general than classes, we should allow the full generality of
Common Lisp types, i.e. arbitrary predications. The problem with that
is that there can be predications that have objects in common, but do
not have a subtype/supertype relationship. Thus if methods are defined
for both predications, it is not clear which method has precedence.
I think the answer is that actually encountering such a method ambiguity
signals an error, but that should not stop you from defining a method on
one predication, only from defining methods on two overlapping
predications. Note that by shadowing the ambiguous method pair with a
method on a more specific class you can prevent the error from being
signalled (I say a more specific class rather than a more specific
predication because the specificness of course has to be computable--see
below).
I strongly believe that it would be a mistake for the type specifiers
in methods to be a whole different type system from the regular Common
Lisp type system. Methods should either allow their arguments to be
qualified with any Common Lisp type specifier, or should restrict the
allowable type specifiers to a certain subset, but there absolutely
should not be extensions to the Common Lisp type system that only work
in method argument lists. That would be too confusing. This means that
the way CommonLoops does methods on individuals now is out. If we're
going to include methods on individuals in the standard, they have to
be done with MEMBER, not with QUOTE. I believe that in fact methods
on arbitrary predications can be implemented, allowing the whole Common
Lisp type system to be supported, and the remainder of this message
is a sketch of one way to implement that.
Any predication can be converted to the canonical form
(OR (AND class1 test1)
(AND class2 test2)...)
where each test is any Common Lisp type expression, and the classes are
all distinct. Any Common Lisp type expression specifies a set of
objects that all belong to some class, even if it's T, along with a
restriction to a subset of the total membership of that class. OR is
introduced essentially as a performance optimization for method
dispatching, to cut down the frequency of resorting to T as the class
for Common Lisp's OR type specifiers. Some kind of rule is required to
decide between minimizing the number of terms in the OR and using the
least general classes. It would also be convenient, but not essential,
to have rules for canonical ordering of the OR terms and canonical
formation of the test type expressions. Some examples:
class-name = (OR (AND class-name T))
(UNSIGNED-BYTE 8) = (OR (AND FIXNUM (INTEGER 0 255)))
;assuming FIXNUM is a class on its own, rather than just having INTEGER
(NOT FLOAT) = (OR (AND T (NOT FLOAT)))
Any two predications can be compared. In fact SUBTYPEP could be used,
but it's easier to think about in terms of the canonical form. I could
write down the rules for how to compare canonical forms in terms of
class precedence and SUBTYPEP on the tests. The result can be a
definite ordering of the predications <, =, >, or disjoint; the latter
means that it is definitely known that no object can satisfy both
predications. The result can also be that the ordering is uncomputable;
this happens when the same class has two different tests and the
ordering of the tests is uncomputable, e.g. SATISFIES of two different
functions. When the ordering is uncomputable, all this means is that
less optimization of the discriminating function is possible; at run time
both predications must be evaluated, and if both are true an error must
be signalled. The discriminating function would exploit the class portion
of the canonical form to avoid evaluating predications when it can prove
from the class that they must be false.
Aside: I don't know whether it's in general safe to trust every
implementation's SUBTYPEP function to work. It would be a pity if the
portable OOP system had to duplicate that functionality.
Aside: I believe the type COMMON is a predication, not a class.
I think so not only because it's so ill-defined, but also because
I can see how you might conceivably define methods on COMMON but
I don't see the point to having a class inherit from COMMON.
As for NULL and VECTOR, we get to decide whether these types are classes
or predications. I think it's clear that VECTOR should be a class,
and we just have to choose some precedence order of ARRAY and SEQUENCE.
The advantage of making NULL a predication rather than a class is that
method clashes between the SYMBOL and LIST classes are guaranteed to
signal an error, instead of using whichever non-obvious precedence order
we happened to choose.
∂08-Sep-86 1458 RPG Re: Defmethod syntax proposal
∂08-Sep-86 0945 Owners-CommonLoopsCore↑.PA@Xerox.COM Re: Defmethod syntax proposal
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Sep 86 09:45:22 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 SEP 86 09:12:45 PDT
Redistributed: CommonLoopsCore↑.PA
Received: from Cabernet.ms by ArpaGateway.ms ; 08 SEP 86 09:11:09 PDT
Date: 8 Sep 86 09:10 PDT
From: Bobrow.pa@Xerox.COM
Subject: Re: Defmethod syntax proposal
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Fri, 5 Sep 86 20:51 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CommonLoopsCore↑.PA@Xerox.COM
Message-ID: <860908-091245-2678@Xerox>
In thinking about it over the weekend, I realized that the syntax we proposed
(defmethod name-or-name-and-options lambda-list ...)
where name-or-name-and-options = name|
(name {combine-options}*)|
(name class-name {combine-options}*)
is completely unambiguous whether one is using "classical" syntax and general syntax.
In "classical" syntax, no argument of lambda-list can be type specified.
In general syntax at least one must be specifed if you are using
method combination options.
<classical-method-def>:=(demethod (generic-name type .{combine-options}*)
unqualified-lambda-list body)
<general-method-def>:=(defmethod name qual-or-unqualified-lambda-list body)|
(defmethod (name . {combine-options}*) qualified-lambda-list body)
I do not like having two syntax's as part of the standard. The difference
in typing is only four characters (self) and the general syntax makes it clear what
variable is being used. With compatibility assured, certain implementations
could support the "classical" syntax as a convenience
or a backwards compatibility feature.
In this case I guess I take a minimimalist position.
-- danny
∂08-Sep-86 1500 RPG Re: Defmethod syntax proposal
∂08-Sep-86 1043 Owners-CommonLoopsCore↑.PA@Xerox.COM Re: Defmethod syntax proposal
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Sep 86 10:42:47 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 SEP 86 10:02:36 PDT
Return-Path: <Moon@YUKON.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.PA@XEROX.ARPA
Received: from YUKON.SCRC.Symbolics.COM (SCRC-YUKON.ARPA) by Xerox.COM ;
08 SEP 86 10:00:04 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM
via CHAOS with CHAOS-MAIL id 81811; Mon 8-Sep-86 12:57:58 EDT
Date: Mon, 8 Sep 86 12:58 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Defmethod syntax proposal
To: CommonLoopsCore↑.PA@Xerox.COM
In-Reply-To: <860908-091245-2678@Xerox>
Message-ID: <860908125848.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 8 Sep 86 09:10 PDT
From: Bobrow.pa@Xerox.COM
In thinking about it over the weekend, I realized that the syntax we proposed
(defmethod name-or-name-and-options lambda-list ...)
where name-or-name-and-options = name|
(name {combine-options}*)|
(name class-name {combine-options}*)
is completely unambiguous whether one is using "classical" syntax and general syntax.
In "classical" syntax, no argument of lambda-list can be type specified.
In general syntax at least one must be specifed if you are using
method combination options.
<classical-method-def>:=(demethod (generic-name type .{combine-options}*)
unqualified-lambda-list body)
<general-method-def>:=(defmethod name qual-or-unqualified-lambda-list body)|
(defmethod (name . {combine-options}*) qualified-lambda-list body)
That was my original proposal, which foundered on the CommonLoops "default
method" feature, which allows defining a "general" method with no type
specifiers. I don't see why method combination options would be
disallowed for default methods. If it doesn't make sense to allow such
options for default methods, then we can go back to that proposal. I'd be
willing to give up the feature of type qualifying additional arguments
while still using classical syntax, for the sake of agreement.
I do not like having two syntax's as part of the standard. The difference
in typing is only four characters (self) and the general syntax makes it clear what
variable is being used.
No, the important difference is that in the classical syntax you don't have to
say "with" explicitly.
With compatibility assured, certain implementations
could support the "classical" syntax as a convenience
or a backwards compatibility feature.
In this case I guess I take a minimimalist position.
I wasn't able to figure out what this means.
∂08-Sep-86 1500 RPG Class versus Type System
∂08-Sep-86 1043 Owners-commonloopscore↑.pa@Xerox.COM Class versus Type System
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Sep 86 10:43:08 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 SEP 86 10:26:33 PDT
Return-Path: <RPG@SAIL.STANFORD.EDU>
Redistributed: commonloopscore↑.pa
Received: from SAIL.STANFORD.EDU (SU-AI.ARPA) by Xerox.COM ; 08 SEP 86
10:26:19 PDT
Date: 08 Sep 86 10:25 PDT
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Subject: Class versus Type System
To: commonloopscore↑.pa@Xerox.COM
Message-ID: <860908-102633-2759@Xerox>
For those who have problems with English, I'll rephrase my remark
and add a few more.
Rephrased remark:
We, the people who are designing the new specification of the Common Lisp
Object System, must take into consideration the fact that, as it currently
stands, there is a distinction between the Common Lisp type system and the
proposed Common Lisp Object System class system. In order for us to keep
our own terminology straight, I have proposed the term `argument
specifier,' which, loosely speaking, is equivalent to the term `type
specifier' that Moon uses.
Further remarks:
(1) I believe that the Common Lisp type, COMMON, is well-defined. However,
it is possible that people do not have a good model of what it comprises;
also it is possible that COMMON would not be a particularly useful class
within the context of the Common Lisp Object System class system.
(2) Extending the Common Lisp Object System class system to include the
sorts of type predications that the Common Lisp type system admits strikes
me as misguided. First, considering implemenations, SUBTYPEP does not, I
believe, behave uniformly over all Common Lisp implementations; that is, I
believe, although I have no examples at hand, that are two Common Lisp
implementations and two type specifiers, S1 and S2, such that one
implementation returns the values NIL NIL when it evaluates the expression
(subtypep s1 s2) whereas the second implementation returns NIL T when it
evaluates the same expression: it is possible that worse discrepancies
exist. Second, considering implementation technology, the Common Lisp
implementations that supply a SUBTYPEP that behaves in such a way that
most observers would conclude that those Common Lisp systems supply a
SUBTYPEP that produces the most consistently accurate results over a set
of test cases for SUBTYPEP, where the observers are considering most of
the available Common Lisp systems, are Common Lisp systems in which the
implementation of SUBTYPEP is more inefficient than those that are judged
to be less accurate. The implication of this observation is that generic
function invocation is likely to be an expensive operation if SUBTYPEP is
used as part of the basic method selection implementation. The
implication of the first observation is that it is likely that it will be
required of the implementors of the basic method selection functions to
use a common implementation (at some level of abstraction), or else the
behavior of the basic method selection functions will need to be specified
in great detail. My third remark is based on hearsay: I know three
mathematicians who regard the Common Lisp type system and SUBTYPEP
in particular with extreme disdain. If any reader of this wishes, I will
interview these individuals to learn their reasons for disdain and
report those reasons.
-rpg-
∂08-Sep-86 1529 RPG Re: Methods Selected by Predications More General Than Classes
∂08-Sep-86 1147 Owners-CommonLoopsCore↑.PA@Xerox.COM Re: Methods Selected by Predications More General Than Classes
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Sep 86 11:47:04 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 SEP 86 10:51:10 PDT
Redistributed: CommonLoopsCore↑.PA
Received: from Cabernet.ms by ArpaGateway.ms ; 08 SEP 86 10:50:46 PDT
Date: 8 Sep 86 10:50 PDT
From: Bobrow.pa@Xerox.COM
Subject: Re: Methods Selected by Predications More General Than Classes
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Fri, 5 Sep 86 22:52 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CommonLoopsCore↑.PA@Xerox.COM
Message-ID: <860908-105110-2796@Xerox>
The following message (about arg specification) appears to have
been lost in the network...
I had not seen it.
I strongly believe that it would be a mistake for the type specifiers in
methods to be a whole different type system from the regular Common Lisp
type system. Methods should either allow their arguments to be qualified
with any Common Lisp type specifier, or should restrict the allowable type
specifiers to a certain subset, but there absolutely should not be
extensions to the Common Lisp type system that only work in method
argument lists. That would be too confusing.
I disagree. I think the set of specifiers for methods need not overlap
the Common Lisp type system. Therefore I do not feel at all
uncomfortable with having a different set of specifications based on
classes and individuals.
HOWEVER, after rereading Moon's message, I felt that he has proposed a
reasonable extension to the current specification mechanism. Subtypep
must be extended to include
(subtypep class-name1 class-name2)
if (subclassp (class-named class-name1) (class-named class-name2))
I would want to extend the type system to deal with
(QUOTE inst) as a short hand for
(SATISFIES (MEMBER '(inst))
since individuals are so useful in type specification.
This imlies the following which is peculiar but OK.
(typep x ''inst) = (eql x 'inst)
We can think of methods for a generic function as specifying a (nested)
set of guarded clauses. The nesting is determined by subtypep
relationships.
I think we must trust every implementations subtypep, despite Moon's
worry. Having two different but similar features in the language is
exactly what we are trying to avoid extending the argument specification
to the full type system.
Since the implementation for classes and individuals as specifiers will
clearly be both the most efficient, and most useful, we might postpone
the description of this to the advanced chapter.
Moon's OR hack should be in implementation notes.
-- danny
∂08-Sep-86 1533 RPG Class versus Type System
∂08-Sep-86 1147 Owners-commonloopscore↑.pa@Xerox.COM Class versus Type System
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Sep 86 11:47:42 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 SEP 86 11:39:07 PDT
Return-Path: <Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM>
Redistributed: commonloopscore↑.pa@XEROX.ARPA
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM ([192.10.41.41]) by
Xerox.COM ; 08 SEP 86 11:38:43 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 76448;
Mon 8-Sep-86 14:13:18 EDT
Date: Mon, 8 Sep 86 14:13 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Class versus Type System
To: commonloopscore↑.pa@Xerox.COM
In-Reply-To: <860908-102633-2759@Xerox>
Message-ID: <860908141318.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 08 Sep 86 10:25 PDT
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
....The implication of this observation is that generic
function invocation is likely to be an expensive operation if SUBTYPEP is
used as part of the basic method selection implementation.
Since method selection operates (conceptually; I'm not talking about
implementations, which no doubt will all use techniques that are more
optimal than this, but provide the same semantics) by doing a series
of TYPEP tests where the first argument is an argument to the generic
function and the second argument is a type specifier from the lambda list
of a method, I fail to see how the expense of SUBTYPEP could affect the
expense of generic function invocation, since even conceptually SUBTYPEP
is not called during generic function invocation.
The thing SUBTYPEP is useful for is deciding in what order to do those
TYPEP tests. This happens when constructing the discriminator, not
every time a generic function is invoked.
It's all the same to me if we decide that for practical or other reasons
we don't want to generalize to allow arbitrary Common Lisp type
specifiers to qualify method arguments, but instead decide to limit
these to some subset, even as small a subset as just class names. Even
though I think it's quite clear how to do the full generalization, I am
always opposed to premature standardization on ideas that have not been
tested in the field. As I've said before, the one thing we must not do
is to develop yet another type system that is not just a subset of the
regular type system.
....The
implication of the first observation is that it is likely that it will be
required of the implementors of the basic method selection functions to
use a common implementation (at some level of abstraction), or else the
behavior of the basic method selection functions will need to be specified
in great detail.
Surely it will be a disaster if the specification of this standard is so poor
that users can't figure out what it specifies, except by experimenting with
a particular implementation that is said to implement the standard. I hope I
misunderstood you.
∂08-Sep-86 1535 RPG Generic Functions Defined by Defmethod
∂08-Sep-86 1245 Owners-commonloopscore↑.pa@Xerox.COM Generic Functions Defined by Defmethod
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Sep 86 12:45:05 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 08 SEP 86 11:54:23 PDT
Return-Path: <RPG@SAIL.STANFORD.EDU>
Redistributed: commonloopscore↑.pa
Received: from SAIL.STANFORD.EDU (SU-AI.ARPA) by Xerox.COM ; 08 SEP 86
11:53:50 PDT
Date: 08 Sep 86 10:53 PDT
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Subject: Generic Functions Defined by Defmethod
To: commonloopscore↑.pa@Xerox.COM
Message-ID: <860908-115423-2902@Xerox>
My comments regarding the situation in which DEFMETHOD creates
a generic function in case there is not already one is based on
my belief of the model that users will develop for generic functions
rather than on implementation considerations, which considerations Moon
believes that I have in mind when I make such remarks.
Let me be more precise. Consider the combination
(defmethod gf ...)
and let us suppose that there is no generic function already
associated with the name, `gf.' Should the defmethod expression
above create a generic function and associate it with the name,
`gf'? My belief of the model that most users of the Common Lisp
Object System will develop is that of a generic function being an
object, some of whose parts comprise the methods defined or specified
by the various defmethod forms which are evaluated and which
specify the same name with which the generic function in question
is associated. Given the belief that generic functions are primary,
will users be confused by the fact that defmethod, a special form
or macro that is used to define a subpart of an object, creates the
object of which it is a subpart if the object does not already exist?
I believe that they will be confused.
There are two techniques we can use to define defmethod in such a
way that defmethod will create the generic function in case it does
not already exist:
(1). we can define a generic function as an abstract data type
whose signature (the operations that can be used on instances
of the abstract data type) includes defmethod along with the
functionality of creating generic functions.
One possible concern with this approach is that the signature
requires possibly confusing-to-the-user behavior from such
functions as SYMBOL-FUNCTION. I have not explored this behavior
in detail.
(2). we can state that when the Common Lisp Object System is loaded,
every symbol has (or can be considered to have) a generic function
associated with it such that this default generic function has no
methods associated with it and such that the other properties of
the generic function have such default values as we may define.
In this way, DEFMETHOD can be crisply defined to operate on
the subparts of a generic function while still retaining
the functionality Bobrow desires.
I apologize to Moon for the fact that my explanation of my belief of the
model that users will develop for generic functions included an analogy
which was presented using a piece of code, which presentation in terms of
code apparently caused him to believe that my concern was for the
implementation details of generic functions rather than for the user model
of the situation.
-rpg-
∂08-Sep-86 1537 RPG Re: Defmethod syntax proposal
∂08-Sep-86 1413 Owners-CommonLoopsCore↑.PA@Xerox.COM Re: Defmethod syntax proposal
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Sep 86 14:13:15 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 08 SEP 86 13:13:17 PDT
Redistributed: CommonLoopsCore↑.PA
Received: from Cabernet.ms by ArpaGateway.ms ; 08 SEP 86 13:13:06 PDT
Date: 8 Sep 86 13:13 PDT
From: Bobrow.pa@Xerox.COM
Subject: Re: Defmethod syntax proposal
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Mon, 8 Sep 86 12:58 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CommonLoopsCore↑.PA@Xerox.COM
Message-ID: <860908-131317-2999@Xerox>
I don't see why method combination options would be disallowed for
default methods. If it doesn't make sense to allow such options
for default methods, then we can go back to that proposal.
I think of defmeth with no argument specification as basically a defun
followed by a make-specializable. If one wants to provide combination
for all methods, than a class specifier of T would allow use of method
combination with full scope.
No, the important difference is that in the classical syntax you
don't
have to say "with" explicitly.
I think it might be a good idea to provide a simple syntax for WITH in
the type specification; for example, ((X class-foo :with-vars) in the
arglist.
With compatibility assured, certain implementations
could support the "classical" syntax as a convenience
or a backwards compatibility feature.
In this case I guess I take a minimimalist position.
I wasn't able to figure out what this means.
I meant that I propose that we not describe classical syntax as part of
the standard. It would simply be a backwards compatibility feature for
Flavors users.
-- danny
∂08-Sep-86 1654 RPG Re: Defmethod syntax proposal
∂08-Sep-86 1614 Owners-CommonLoopsCore↑.PA@Xerox.COM Re: Defmethod syntax proposal
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Sep 86 16:10:29 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 08 SEP 86 15:50:27 PDT
Return-Path: <DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.PA@XEROX.ARPA
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM ([192.10.41.41]) by
Xerox.COM ; 08 SEP 86 15:50:12 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by
ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 76801;
Mon 8-Sep-86 18:39:41 EDT
Date: Mon, 8 Sep 86 18:41 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: Re: Defmethod syntax proposal
To: Bobrow.pa@Xerox.COM
cc: CommonLoopsCore↑.PA@Xerox.COM
In-Reply-To: <860908-131317-2999@Xerox>
Message-ID: <860908184131.4.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: 8 Sep 86 13:13 PDT
From: Bobrow.pa@Xerox.COM
I meant that I propose that we not describe classical syntax as part of
the standard. It would simply be a backwards compatibility feature for
Flavors users.
It's really more than that; it provides conceptual compatibility for
people who are familiar with most any of the other existing
object-oriented programming languages, particularly Smalltalk-80.
It provides the familiar concepts of instance variables and "self".
Because of the widespread establishment of these concepts, I think
it's worth putting this into the standard for everyone, despite the
minor inelegance of having two syntaxes when only one is logically
necessary.
∂08-Sep-86 1654 RPG Generic Functions Defined by Defmethod
∂08-Sep-86 1614 Owners-commonloopscore↑.pa@Xerox.COM Generic Functions Defined by Defmethod
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Sep 86 16:10:22 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 08 SEP 86 15:29:40 PDT
Return-Path: <DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM>
Redistributed: commonloopscore↑.pa@XEROX.ARPA
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM ([192.10.41.41]) by
Xerox.COM ; 08 SEP 86 15:29:22 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by
ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 76792;
Mon 8-Sep-86 18:28:03 EDT
Date: Mon, 8 Sep 86 18:29 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: Generic Functions Defined by Defmethod
To: RPG@SAIL.STANFORD.EDU, commonloopscore↑.pa@Xerox.COM
In-Reply-To: <860908-115423-2902@Xerox>
Message-ID: <860908182948.3.DLW@CHICOPEE.SCRC.Symbolics.COM>
I understand the point you're making. As I've said, I'm undecided on
this issue personally, but since I believe I understand the other side
of the argument, I'll speak for it. I think the answer to your point is
as follows:
The analogy you presented with cons cells, is, as you said, extreme.
The opposite extreme analogy might be to insist that, in Lisp, one
explicitly create each symbol before using it, by calling intern on a
string, or something. After all, the appearance of a symbol means that
it should be looked up in a table; isn't it confusing that sometimes it
should create a symbol rather than looking one up?
Or, to abandon extreme analogies and speak more plainly, the proposed
conceptual model for why defmethod should create a generic function is
that "it's like intern"; the first mention causes an automatic creation,
to save you the trouble of doing one manually.
∂08-Sep-86 1727 RPG Re: Defmethod syntax proposal
∂08-Sep-86 1705 Owners-CommonLoopsCore↑.PA@Xerox.COM Re: Defmethod syntax proposal
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Sep 86 17:05:04 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 08 SEP 86 16:13:56 PDT
Redistributed: CommonLoopsCore↑.PA
Received: from Cabernet.ms by ArpaGateway.ms ; 08 SEP 86 16:13:39 PDT
Date: 8 Sep 86 16:13 PDT
From: Bobrow.pa@Xerox.COM
Subject: Re: Defmethod syntax proposal
In-reply-to: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>'s
message of Mon, 8 Sep 86 18:41 EDT
To: DLW@ALDERAAN.SCRC.Symbolics.COM
cc: Bobrow.pa@Xerox.COM, CommonLoopsCore↑.PA@Xerox.COM
Message-ID: <860908-161356-3282@Xerox>
Date: 8 Sep 86 13:13 PDT
From: Bobrow.pa@Xerox.COM
I meant that I propose that we not describe classical syntax as
part
of the standard. It would simply be a backwards compatibility
feature
for Flavors users.
It's really more than that; it provides conceptual compatibility
for
people who are familiar with most any of the other existing
object-oriented programming languages, particularly Smalltalk-80.
It provides the familiar concepts of instance variables and "self".
Because of the widespread establishment of these concepts, I think
it's worth putting this into the standard for everyone, despite the
minor inelegance of having two syntaxes when only one is logically
necessary.
(defmethod foo ((self class-name) ...) provides self as a cliche, and
allows those users the optioning of providing a more mnemonic name for
self. Instance variables (or slots as we are calling them) are
available in either case. Using the general syntax also encourages
users to remmber that this is a generic function and others may define
extensions (new defmethods) that specialize more than one argument. I
think that separate syntax will cause mind bugs of the sort -- 'well I
did a "classical" defmethod so now I can't specialize other args.'
-- danny
∂08-Sep-86 1728 RPG Class versus Type System
∂08-Sep-86 1707 Owners-commonloopscore↑.pa@Xerox.COM Class versus Type System
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Sep 86 17:05:20 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 08 SEP 86 16:21:02 PDT
Return-Path: <DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM>
Redistributed: commonloopscore↑.pa@XEROX.ARPA
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM ([192.10.41.41]) by
Xerox.COM ; 08 SEP 86 16:20:48 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by
ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 76812;
Mon 8-Sep-86 19:19:38 EDT
Date: Mon, 8 Sep 86 19:21 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: Class versus Type System
To: Moon@STONY-BROOK.SCRC.Symbolics.COM, commonloopscore↑.pa@Xerox.COM
In-Reply-To: <860908141318.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <860908192128.5.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Mon, 8 Sep 86 14:13 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Surely it will be a disaster if the specification of this standard is so poor
that users can't figure out what it specifies, except by experimenting with
a particular implementation that is said to implement the standard. I hope I
misunderstood you.
Well, I think RPG is probably right about SUBTYPEP being inconsistent
from one implementation to the next. As I see it, SUBTYPEP is answering
the following question: "Is it the case that for all objects X, such
that X is of type T1, it is necessarily true that X is of type T2"? The
problem is that there are two interpretations of this question. One
interpretation asks "... for all objects X where X is any object that
can exist in this particular superset of Common Lisp ...", and the other
interpretation asks "... for all objects X where X is any object that
can exist in every Lisp that is a subset of Common Lisp ...". If two
implementations both use the first interpretation, it's easy to see how
they might be inconsistent.
I think that specific cases of this problem have been discussed on
Common-Lisp, but I don't remember the details. I could be wrong about
this. They have to do with areas in which the implementor is given
latitude, such as the decision of how to implement instances of
defstructs and things like that. An easy example might be
(subtypep 'single-float 'short-float)
in an implementation in which they are the same thing. This
form returns T T in our implementation.
∂09-Sep-86 2035 RPG Re: Subtypep
∂09-Sep-86 1947 Bobrow.pa@Xerox.COM Re: Subtypep
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Sep 86 19:47:18 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 09 SEP 86 17:52:00 PDT
Date: 9 Sep 86 17:46 PDT
From: Bobrow.pa@Xerox.COM
Subject: Re: Subtypep
In-reply-to: Dick Gabriel <RPG@SAIL.STANFORD.EDU>'s message of 08 Sep 86
17:35 PDT
To: RPG@SAIL.STANFORD.EDU
cc: commonloopscore↑.pa@Xerox.COM
Message-ID: <860909-175200-1153@Xerox>
CLASS-OF will be as poorly defined as the current TYPE-OF.
Why is this ill-defined? It is not TYPE-OF. It returns the most
specific class for the instance.
-- danny
∂09-Sep-86 2244 RPG Re: Summary of features we all agree on
∂09-Sep-86 2158 Owners-CommonLoopsCore↑.PA@Xerox.COM Re: Summary of features we all agree on
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Sep 86 21:58:11 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 09 SEP 86 21:41:34 PDT
Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.PA@XEROX.ARPA
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
Xerox.COM ; 09 SEP 86 21:40:45 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 99736; Wed
10-Sep-86 00:39:48 EDT
Date: Wed, 10 Sep 86 00:39 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Re: Summary of features we all agree on
To: CommonLoopsCore↑.PA@Xerox.COM
In-Reply-To: <860905-184912-1633@Xerox>
Message-ID: <860910003916.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 5 Sep 86 18:49 PDT
From: Bobrow.pa@Xerox.COM
(DEFCLASS class-name (slot-spec...) (super-class-name...)
option...)
Not quite. We have the opposite order for (super-class-name...)
and (slot-spec...).
(DEFCLASS class-name (super-class-name...) (slot-spec...)
option...)
We can probably go along with this, but it ought to be
discussed. What was the motivation for changing the order?
class-name is a non-null symbol that names the class being
defined. If a class is already defined with this name, this
definition replaces the old definition. The default
meta-class ensures that when the definition of a class
changes, each existing instance of the class is updated to the
new format the next time it is accessed.
Each slot-spec is one of:
slot-name a non-null symbol.
(slot-name initial-value-form)
(slot-name slot-option...)
Each slot-option is an option name followed by its value.
The defined slot-options and their arguments are:
= initial-value-form
This an alternate way for providing a default
initial value form.
How is this form distinguished from the previous. By having more than
two elements???
Yes. (slot-name initial-value-form) is a convenient
abbreviation for (slot-name = initial-value-form).
How do you not give an init value form.
The way you omit the initial value form when giving slot-options
is to omit the = slot-option. I thought this was discussed in
the mail a while back but I could be misremembering.
By the way I'm not wedded to the name "=". I couldn't think of
a clearer name when I tried for a few minutes, but perhaps
someone else can.
:accessor generic-function-name
Specifies that a function named generic-function-name
be automatically generated, to read the value of this
slot. SETF may be used with generic-function name to
write the value of the slot.
OK. If generic-function-name is NIL then this is a NOOP.
Specified so programs can generate these.
:reader generic-function-name
Specifies that a function named generic-function-name
be automatically generated, to read the value of this
slot.
We have called this :read-accessor.
I think users would find the distinction between :read-accessor
and :accessor confusing. Perhaps we need some more opinions
here, it's a difficult judgement.
We specify that if this is
given, then SETF may NOT be used with this accessor. If
generic-function-name is NIL then this is a NOOP.
Agreed.
:initable keyword
Specifies a keyword to be used to specify an
initial value of this slot, when a new instance is
being made.
I think this is OK. Should allow value of NIL. Default is T
I don't think you meant it when you said "default is T", since
the argument is a keyword. If you meant that unless the
programmer specifies otherwise, all slots can be initialized by
MAKE with keywords chosen by default, I don't think that is good
data abstraction. I don't think slots should be visible from
outside of the module that owns a class unless the definer of
the class explicitly makes them visible. We can provide a
defclass option that makes it very easy to make all the slots
initializable, but the default should be that features like this
are turned off until the programmer turns them on. This is the
same argument as the one that made us all decide that slot
accessors are not created unless the programmer asks for them.
:allocation
:allocation can have values
:instance (allocated in the instance),
:class (storage allocated in the class and shared by all
instances),
:dynamic (storage allocated in the instance on first use
(like Flavors Proplist mixin)
:none expect accessor methods for this to be defined for
this slot in this class
We need to discuss which of these allocation options belong in
the standard. Maybe only a subset of them.
:initialize-only flag
If flag = T, then this slot cannot be changed after
initialization (a better name for :read-only). flag=T implies
no accessors are generated. default is NIL.
Do we really need this feature? Why not just leave out the
:accessor if we don't want people to be able to setf the slot?
If no initial value is specified either in the DEFCLASS or the
MAKE form, the initial value of the slot is undefined and it
is an error to reference it. This is the same behavior as a
DEFVAR with no initial-value-form.
We hate these "it is an error" statements. We haven't discussed
this particular issue.
I don't think the object-oriented programming standard should
try to be the error-handling standard, too! Let's just say that
referencing an uninitialized slot has the same error
characteristics as referencing an uninitialized special
variable, and leave it to the rest of the language to define
just what that is.
Each super-class-name is a non-null symbol.
Each option is one of:
option-name
(option-name argument...)
Each option-name is a keyword that names an option; the
arguments depend on the option.
OK
The set of defined options and their arguments is:
(:accessor-prefix prefix slot-name...)
(:reader-prefix prefix slot-name...)
(:default-init-plist keyword-argument...)
(:initable-slots slot-name...)
(:init-keywords keyword...)
The only one of these that we have agreed to is:
(:accessors-with-prefix string-or-symbol)
which causes accessors to be generated with the given prefix for
ALL slots that do not have local specification of any of
:accessor, :read-accessor, or :initialize-only. If this form
does not appear, then no accessors for slots are generated.
Note they we have made this be a single default that applies
uniformly. No specific slots can be mentioned, and this option
can appear only once. The arguments for this way of doing
business are:
1) Anything not uniform is local to a slot description
2) There are no redundant, possibly inconsistent,
declarations
:accessors-with-prefix is certainly nice and simple, but it is
not the same as the last thing that was discussed in the mail.
And the other options were listed because they appeared in
"things we basically agree on" in the minutes of that meeting we
had at MIT, so we need to keep discussing this until we converge.
(:documentation string)
OK
(:meta-class class-name)
No, we think this should be done using the meta-object protocol,
since the parsing of the defclass is not under the control of
the meta-class. However, I think we could be convinced
otherwise.
You're the meta-class experts, but I think the idea of this
option was supposed to be to control the class of the class that
gets instantiated, but not to affect anything about the parsing
of the defclass.
(:required-classes class-name...)
(:required-init-keywords keyword...)
(:required-slots slot-name...)
(:required-methods generic-function-name...)
No. These seem like environmental features, and should not be
part of the spec.
I think you're wrong here, for two reasons. One is that I don't
agree that these are environmental; I see them as a necessary
part of defining a class and its relationships with other
classes. We've found these options to be heavily used when
setting up complex families of classes.
The second reason is that these aren't just error-checking.
:required-slots and :required-classes can make additional slot
names available as variables inside a WITH. This is necessary
to be able to write methods for abstract classes, and especially
for mixins, when part of the inter-component-class interface
takes the form of slots.
If we disagree we need to keep discussing this.
We should make some comment about how
additional options may be supported by the standard class in
particular implementations, and ones not understood will either
be ignored, or have warnings issued.
I don't think having defclass options quietly ignored in some
implementations is going to enhance portability.
(:constructor function-name lambda-list)
We have allowed the full generality of the defstruct syntax for
this one. Do you think it should be restricted to this
boa-constructor
No, I agree. Specifically, the lambda-list should be optional,
and default to (&key ...) where the ... is filled in according
to the :initable and :initable-slots (or whatever those options
end up being called) in the obvious way.
For the :ACCESSOR-PREFIX, :READER-PREFIX, and :INITABLE-SLOTS
options, you can omit slot-names to indicate that the option
applies for all slots of this class.
See above
It is legal to specify more than one accessor and reader for a
single slot.
We argued about this, and decided we didn't like it. Why is it good?
I think I pointed out in an earlier piece of mail that you might
want to have both an accessor and a reader, where the accessor
is used inside of a module while the reader is a public
interface. The idea is that you can't change the contents of
the slot using the public interface. I don't know of
applications for two accessors or two readers, but I don't see
any advantage to adding a special error-check to disallow that.
Why is it bad?
DEFINING METHODS AND SETF METHODS
The general syntax for defining a method is:
(DEFMETHOD generic-function-name method-option...
method-lambda-list
body...)
No. See my earlier message.
At the time Sonya and I put together this list of things that
we thought had been agreed upon, we didn't know that there was
still disagreement on the syntax of defmethod, since we had not
heard from you. As it turns out defmethod isn't ready to be
included yet. We need to keep working on it until we converge.
...But we agree that DEFMETHOD-SETF
is a better name.... Are we not allowing multiple values to be
stored? In the silver book it talks about extensions to the
corresponding list of store variables. I have no problem with
the restriction.
The extension mentioned on CLtL p.103 hasn't been incorporated
into Common Lisp yet, so I don't think it should be allowed to
sneak in through the object-oriented programming extension.
We should leave syntactic space for it, though, so having the
store-variable in a separate lambda-list is good.
DEFINING GENERIC FUNCTIONS
(DEFGENERIC generic-function-name lambda-list option...)
(DEFGENERIC-SETF generic-function-name lambda-list
setf-lambda-list option.
generic-function-name is a non-null symbol.
lambda-list is an ordinary lambda-list except no &aux
variables are allowed.
setf-lambda-list is (variable-name).
Yes, except that we allow a documentation string before the
options. What do you think???
Flavors allows a "naked" documentation string also, but I'm not
sure that ought to be in the standard. It's a matter of whether
you think it's more important to have the options in a uniform
format or to have defgeneric syntax be more analogous to defun
syntax.
Each option is one of:
option-name
(option-name argument...)
Each option-name is a keyword that names an option; the
arguments depend on the option.
OK
The set of defined options and their arguments is:
[--Should declarations and doc strings be allowed?--]
(:documentation string)
See above.
(:optimize spec...)
Is this for all methods, or just the discriminating function.
This seems weird to me
The question seems weird to me. I guess the problem is caused
by us including only the syntax and not the semantics so as to
get something out quickly for discussion, which meant that we
completely failed to communicate what this was all about.
The idea of the :optimize option to defgeneric in Flavors is
that there are a variety of possible ways of doing
discrimination, and in order for the system to choose among them
intelligently the user should be able to express his needs. In
the Common Lisp objected-oriented programming facility I presume
it would be a method of the discriminator, rather than
"the system", that is guided by this option, but otherwise the
concept of the :optimize option seems to carry over directly and
does not seem to be at all specific to Flavors. I believe it's
more portable for the user's needs to be expressed in terms of
which quality (speed or space) is more important, rather than
directly specifying the exact technique to be used.
(:method-combination name argument...)
What is the argument in this form?
Optional arguments received by parameters in the
define-method-combination. See the Flavors documentation.
(:generic-function-class class-name)
(:method-class class-name)
(:order parameter-name...)
We have been using :dispatch-order for the keyword :order. It
should really be :argument-precedence-order.
:argument-precedence-order is the best name I've heard for this
yet.
[more?]
Additional options should be allowed, as in defclass.
WITH
We have agreed that WITH should exist, but we haven't decided
anything more specific about it yet.
Right; we haven't decided anything yet. There are two different
proposals under discussion. One turns names in calls on the
accessors (we call that one WITH). The other turns them into
primitive slot accesses (we call that one %WITH).
No proposal is "under discussion" if the people on the east coast
haven't seen it. Send them along and we'll be happy to discuss
them.
DEFINING NEW TYPES OF METHOD COMBINATION
(DEFINE-SIMPLE-METHOD-COMBINATION name operator-name
[single-arg-is-value]
[pretty-name])
This function defines a new type of method combination in
which all the methods are called and their values are passed
to the operator specified by operator-name.
name is a non-null symbol, often a keyword, that is the name
of the type of method combination being defined.
operator-name can be a symbol or a lambda-expression, the name
of a function, a macro, or a special form.
single-arg-is-value is t or nil; by default it is nil.
pretty-name is a string. It defaults to the lower case
version of the supplied name.
We haven't agreed to this at all yet. super-daemon method
combination we believe in. But this simple case seems strange to
me, and if it can be defined with the stronger
DEFINE-METHOD-COMBINATION, then let's not put it in the spec.
It's a convenient abbreviation for people who don't want to have
to understand the full define-method-combination to do something
simple. What are you going to tell the user whose program is
non-portable because you decided to leave this out?
I didn't see whoppers described in daemon combination section of
the Flavors manual -- at least not in the early section. Does
this mean that it is not a feature of daemon combination?
Whoppers are described in their own section. They are not a
feature of daemon combination or any other particular type of
combination.
We believe that at least on the west coast, run-super will be
used much more than daemon combination. Hence my attempt to
unify them. An answer to Moons answer next week.
(DEFINE-METHOD-COMBINATION method-combination-type-name
lambda-list
(method-pattern...)
option...
body...)
This function behaves the same way as in Flavors. See the
Flavors documentation for details.
We believe that a simple version of this should be in the spec.
I don't know yet what simple means. At least powerful enough to
define the extended features, but not including the full library
of standardly available combinations types.
Making a New Instance
(MAKE class-name keyword-argument...)
MAKE is the function that makes and initializes an instance of
a class. The allowed keyword-arguments depend on the DEFCLASS
form. Any keyword specified with the :INITABLE,
:INITABLE-SLOTS, or :INIT-KEYWORDS option is allowed.
If a keyword-argument is given to MAKE, it overrides any
default that is given in the DEFCLASS form, such as the
:DEFAULT-INIT-PLIST option, or the initial-value-form syntax.
Modulo isssues on keywords and specification of initable, this
is basically correct.
OTHER FUNCTIONS
Other functions of interest to the general programmer
[---tbd---].
This list came from the 8 August meeting; it can serve as a
starting agenda for this section:
find-flavor / class-named
Yes class-named
typep
classp is the right name
The name TYPEP is already specified by Common Lisp, we can't
change it to something else. The issue here is what is to be
changed in the documentation of typep when the object-oriented
programming extension is added to the Common Lisp specification.
type-of
class-of
Yes on class-of
operation-handled-p ??
Something like this is needed
remove-class
remove-method
change-class
Yes
If we can discuss and reach agreement upon the few points of
disagreement above, we should be able to send out a revised
version of "Summary of features we all agree on" in a couple
of days and then move on to deeper issues.
∂09-Sep-86 2244 RPG lack of word from the west coast
∂09-Sep-86 2158 Owners-CommonLoopsCore↑.PA@Xerox.COM lack of word from the west coast
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Sep 86 21:58:03 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 09 SEP 86 21:35:06 PDT
Return-Path: <Moon@ALDERAAN.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.PA@XEROX.ARPA
Received: from ALDERAAN.SCRC.Symbolics.COM ([192.10.41.109]) by
Xerox.COM ; 09 SEP 86 21:34:51 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 3422; Wed
10-Sep-86 00:33:50 EDT
Date: Wed, 10 Sep 86 00:33 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: lack of word from the west coast
To: CommonLoopsCore↑.PA@Xerox.COM
Message-ID: <860910003335.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
The draft document outlining what has been learned so far
in the Xerox/Lucid meetings, which you said you would send
by the end of last week, has not yet arrived. I think you
had better send it again.
∂09-Sep-86 2324 RPG Class-of Versus Type-of
∂09-Sep-86 2258 Owners-commonloopscore↑.pa@Xerox.COM Class-of Versus Type-of
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Sep 86 22:57:36 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 09 SEP 86 22:53:12 PDT
Return-Path: <RPG@SAIL.STANFORD.EDU>
Redistributed: commonloopscore↑.pa
Received: from SAIL.STANFORD.EDU (SU-AI.ARPA) by Xerox.COM ; 09 SEP 86
22:53:02 PDT
Date: 09 Sep 86 22:52 PDT
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Subject: Class-of Versus Type-of
To: commonloopscore↑.pa@Xerox.COM
Message-ID: <860909-225312-1464@Xerox>
Danny asked what I meant when I said that class-of might be ill-defined
in some situation. The situation I thought I was discussing was
the one in which the Common Lisp type system is subsumed by the
class system, and class-of is possibly expected to return `the
most specific class' in the presence of type specifiers which correspond
to classes and in the presence of types/classes that do not exist in
every Common Lisp (like simple- objects). Class-of is perfectly
well-defined in the current proposal in which the Common Lisp standard
type specifiers (minus atom and common) have (builtin) classes.
(Danny, I'm referring to the current West Coast proposal).
-rpg-
∂09-Sep-86 2336 RPG Things on which we agree
∂09-Sep-86 2326 Owners-commonloopscore↑.pa@Xerox.COM Things on which we agree
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Sep 86 23:26:33 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 09 SEP 86 23:24:49 PDT
Return-Path: <RPG@SAIL.STANFORD.EDU>
Redistributed: commonloopscore↑.pa
Received: from SAIL.STANFORD.EDU (SU-AI.ARPA) by Xerox.COM ; 09 SEP 86
23:24:40 PDT
Date: 09 Sep 86 23:24 PDT
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Subject: Things on which we agree
To: commonloopscore↑.pa@Xerox.COM
Message-ID: <860909-232449-1480@Xerox>
Some of the West Coast people prefer MAKE-INSTANCE to MAKE.
The motivation is to leave good names alone when reasonably
short, reasonably descriptive names are available.
********************************************************************
When I read something like:
:accessor generic-function-name
Specifies that a function named generic-function-name
be automatically generated, to read the value of this
slot. SETF may be used with generic-function name to
write the value of the slot.
Should I take it to mean the same as
:accessor generic-function-name
Specifies that a generic function named generic-function-name
be automatically generated, to read the value of this
slot. SETF may be used with generic-function-name to
write the value of the slot.
********************************************************************
On this topic:
:initialize-only flag
Do we really need this feature? Why not just leave out the
:accessor if we don't want people to be able to setf the slot?
Presumably the :accessor option indicates that a setfable accessor is
made, while its absence still leaves (setf (get-slot ...) ...) available?
Or is GET-SLOT not `agreed to?' If GET-SLOT exists and leaves the slot
setfable, then :initialize-only has a role.
********************************************************************
Danny said: ``There are two different are proposals under discussion.''
He was misguided in saying this. He meant that the West Coast discussion
group was discussing this issue and would probably propose an alternative
that mentions WITH and %WITH (or some such names). We usually discuss
things like this out here to try to filter out bad ideas from the set of
ideas we ship to the Hub.
********************************************************************
Is the name of the type of method combination a symbol for some deep
reason or just to keep it a simple name as in other named things?
*********************************************************************
Are whoppers thought of as being in a different ontological category
from other method combination types? The continue-whopper `feature'
seems to hint so.
-rpg-
∂10-Sep-86 0837 RPG Re: [Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>:
∂09-Sep-86 1947 Bobrow.pa@Xerox.COM Re: [Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>:
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Sep 86 19:47:32 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 09 SEP 86 18:34:49 PDT
Date: 9 Sep 86 18:34 PDT
From: Bobrow.pa@Xerox.COM
Subject: Re: [Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>:
Summary of features we all agree on ]
In-reply-to: Kahn.pa's message of 8 Sep 86 14:07 PDT
To: Kahn.pa@Xerox.COM
cc: Bobrow.pa@Xerox.COM, CommonLoopsCore↑.PA@Xerox.COM
Message-ID: <860909-183449-1216@Xerox>
:initialize-only flag
We need to be clear what "after initialization" means. Can one
send an
"initialize-with-plist" message to an "already initialized"
instance?
I think so (How can we stop it?) But that is different than using a
SETF to change the value. Users can almost always get around read-only
declarations not protected by hardware. I prefer the name
:initialize-only to :read-only despite history.
(:meta-class class-name)
There are different uses of meta-classes. There are those that
just
make performance trade-offs and need not be concerned with "the
parsing
of the defclass". It would be reasonable to be able to use the
:meta-class at least in such cases.
I agree.
(MAKE class-name keyword-argument...)
I would prefer that the first argument to MAKE is either a
class-name or
a class.
I agree.
-- danny
∂10-Sep-86 0837 RPG Re: Subtypep
∂09-Sep-86 1947 Bobrow.pa@Xerox.COM Re: Subtypep
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Sep 86 19:47:18 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 09 SEP 86 17:52:00 PDT
Date: 9 Sep 86 17:46 PDT
From: Bobrow.pa@Xerox.COM
Subject: Re: Subtypep
In-reply-to: Dick Gabriel <RPG@SAIL.STANFORD.EDU>'s message of 08 Sep 86
17:35 PDT
To: RPG@SAIL.STANFORD.EDU
cc: commonloopscore↑.pa@Xerox.COM
Message-ID: <860909-175200-1153@Xerox>
CLASS-OF will be as poorly defined as the current TYPE-OF.
Why is this ill-defined? It is not TYPE-OF. It returns the most
specific class for the instance.
-- danny
∂10-Sep-86 1730 RPG Getting together to work
∂10-Sep-86 1633 Gregor.pa@Xerox.COM Getting together to work
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 10 Sep 86 16:33:27 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 10 SEP 86 15:43:08 PDT
Date: 10 Sep 86 15:42 PDT
Sender: Gregor.pa@Xerox.COM
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
Subject: Getting together to work
To: CommonLoopsCore↑.pa@Xerox.COM
cc: Gregor.pa@Xerox.COM
Message-ID: <860910-154308-2286@Xerox>
My messages for the next little while are likely to be more curt than
usual, I can only type with one hand.
We had made a plan to get together monday moring at OOPSLA and work on
the spec. I believe that we will have more work to do than can be done
in three hours.
Instead, I propose that we get together Friday and Saturday after OOPSLA
in Palo Alto. This will give us enough time to actually get some work
done, and takes advantage of existing travel to get a lot of people in
the same place.
I propose that we use the Monday morning at OOPSLA time to have a more
open meeting with people from LMI and HP.
∂11-Sep-86 1057 RPG Things on which we agree
∂10-Sep-86 1919 Owners-commonloopscore↑.pa@Xerox.COM Things on which we agree
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 10 Sep 86 19:19:33 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 10 SEP 86 19:01:23 PDT
Return-Path: <Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM>
Redistributed: commonloopscore↑.pa@XEROX.ARPA
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM ([192.10.41.41]) by
Xerox.COM ; 10 SEP 86 19:01:07 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 78603;
Wed 10-Sep-86 21:59:43 EDT
Date: Wed, 10 Sep 86 21:59 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Things on which we agree
To: commonloopscore↑.pa@Xerox.COM
In-Reply-To: <860909-232449-1480@Xerox>
Message-ID: <860910215951.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 09 Sep 86 23:24 PDT
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Some of the West Coast people prefer MAKE-INSTANCE to MAKE.
The motivation is to leave good names alone when reasonably
short, reasonably descriptive names are available.
Either name is fine with me.
********************************************************************
When I read something like:
:accessor generic-function-name
Specifies that a function named generic-function-name
be automatically generated, to read the value of this
slot. SETF may be used with generic-function name to
write the value of the slot.
Should I take it to mean the same as
:accessor generic-function-name
Specifies that a generic function named generic-function-name
be automatically generated, to read the value of this
slot. SETF may be used with generic-function-name to
write the value of the slot.
I think so. The omission of "generic" before "function" in 1 out of 4
places was probably not intended to mean anything. It should be rephrased
to be consistent.
********************************************************************
On this topic:
:initialize-only flag
Do we really need this feature? Why not just leave out the
:accessor if we don't want people to be able to setf the slot?
Presumably the :accessor option indicates that a setfable accessor is
made, while its absence still leaves (setf (get-slot ...) ...) available?
Or is GET-SLOT not `agreed to?' If GET-SLOT exists and leaves the slot
setfable, then :initialize-only has a role.
Hmm, if you really think get-slot should be customizable this way, then
yes, there should be a slot-option to customize it. Never in a million years
would I have figured out from the name of the slot-option that this is what
it controls, so I think a better name should be found. Except for that,
I'm amenable to putting this in if someone thinks it's important.
I think of get-slot as a subprimitive for getting around the normal
accessor mechanism, so I don't see any point to the extra complexity of
providing ways to turn off get-slot reading and writing. I see even less
point when I think about it harder and suspect that then you would need
a %get-slot, which is the same as get-slot except that it can't be turned
off, as part of the semantics of WITH.
Perhaps other people think of get-slot as something the user would use
all the time, if so that's a bit of a surprise to me. I do think we
agreed that there should be something that does get-slot (called
symbol-value-in-instance in Flavors; I don't much care for either name).
********************************************************************
Danny said: ``There are two different are proposals under discussion.''
He was misguided in saying this. He meant that the West Coast discussion
group was discussing this issue and would probably propose an alternative
that mentions WITH and %WITH (or some such names). We usually discuss
things like this out here to try to filter out bad ideas from the set of
ideas we ship to the Hub.
I haven't been to the Hub in weeks.
********************************************************************
Is the name of the type of method combination a symbol for some deep
reason or just to keep it a simple name as in other named things?
The latter.
*********************************************************************
Are whoppers thought of as being in a different ontological category
from other method combination types? The continue-whopper `feature'
seems to hint so.
Whoppers aren't a method-combination type, they are a kind of method. I
don't know what an ontological category is, but the dictionary
definition of ontological suggests that deleting the word won't change
the meaning of your question. Whoppers (and wrappers) are different
from regular methods because they themselves control the way they get
combined, instead of being controlled by a method-combination routine
defined with define-method-combination.
I should point out again that I don't like whoppers, but I support them
for the standard because I have to admit that my users have found them
very useful. I might not always be the best source of information about
why whoppers are the way they are, for this reason.
∂11-Sep-86 1100 RPG Re: Things on which we agree
∂11-Sep-86 1020 Owners-commonloopscore↑.pa@Xerox.COM Re: Things on which we agree
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Sep 86 10:20:13 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 11 SEP 86 10:03:25 PDT
Redistributed: commonloopscore↑.pa
Received: from Cabernet.ms by ArpaGateway.ms ; 11 SEP 86 10:03:12 PDT
Date: 11 Sep 86 10:03 PDT
From: Bobrow.pa@Xerox.COM
Subject: Re: Things on which we agree
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Wed, 10 Sep 86 21:59 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: commonloopscore↑.pa@Xerox.COM
Message-ID: <860911-100325-2906@Xerox>
On this topic:
:initialize-only flag
Do we really need this feature? Why not just leave out
the
:accessor if we don't want people to be able to setf the slot?
Presumably the :accessor option indicates that a setfable
accessor
is made, while its absence still leaves (setf (get-slot ...)
...) available? Or is GET-SLOT not `agreed to?' If GET-SLOT
exists and leaves the slot setfable, then :initialize-only has
a
role.
Hmm, if you really think get-slot should be customizable this way,
then
yes, there should be a slot-option to customize it. Never in a
million
years would I have figured out from the name of the slot-option
that
this is what it controls, so I think a better name should be found.
Except for that, I'm amenable to putting this in if someone thinks
it's
important.
What does ":read-only" mean in Flavors on a slot? It was my
understanding that it meant that after initialization, one couldn't set
an instance variable in a method. :initialize-only was put in as a
better name (I thought) for :read-only. Perhaps we should drop it as a
mechanism that must be supported by the system.
Whoppers (and wrappers) are different from regular methods because
they
themselves control the way they get combined, instead of being
controlled by a method-combination routine defined with
define-method-combination.
This of course is how we have always done method combination in Loops,
and it has proven most useful to us. We never allowed super classes to
dictate what a subclass would do. Hence the similarity that I saw
between run-super and continue-whopper. If we have run-super in primary
methods should we have :around methods -- and if so, do you prefer the
name :full-shadow for this type. Ontologically this name is much
sounder, of course, if you like that kind of ontology.
-- danny
∂11-Sep-86 1103 RPG Re: Things on which we agree
∂11-Sep-86 1020 Owners-commonloopscore↑.pa@Xerox.COM Re: Things on which we agree
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Sep 86 10:20:13 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 11 SEP 86 10:03:25 PDT
Redistributed: commonloopscore↑.pa
Received: from Cabernet.ms by ArpaGateway.ms ; 11 SEP 86 10:03:12 PDT
Date: 11 Sep 86 10:03 PDT
From: Bobrow.pa@Xerox.COM
Subject: Re: Things on which we agree
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Wed, 10 Sep 86 21:59 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: commonloopscore↑.pa@Xerox.COM
Message-ID: <860911-100325-2906@Xerox>
On this topic:
:initialize-only flag
Do we really need this feature? Why not just leave out
the
:accessor if we don't want people to be able to setf the slot?
Presumably the :accessor option indicates that a setfable
accessor
is made, while its absence still leaves (setf (get-slot ...)
...) available? Or is GET-SLOT not `agreed to?' If GET-SLOT
exists and leaves the slot setfable, then :initialize-only has
a
role.
Hmm, if you really think get-slot should be customizable this way,
then
yes, there should be a slot-option to customize it. Never in a
million
years would I have figured out from the name of the slot-option
that
this is what it controls, so I think a better name should be found.
Except for that, I'm amenable to putting this in if someone thinks
it's
important.
What does ":read-only" mean in Flavors on a slot? It was my
understanding that it meant that after initialization, one couldn't set
an instance variable in a method. :initialize-only was put in as a
better name (I thought) for :read-only. Perhaps we should drop it as a
mechanism that must be supported by the system.
Whoppers (and wrappers) are different from regular methods because
they
themselves control the way they get combined, instead of being
controlled by a method-combination routine defined with
define-method-combination.
This of course is how we have always done method combination in Loops,
and it has proven most useful to us. We never allowed super classes to
dictate what a subclass would do. Hence the similarity that I saw
between run-super and continue-whopper. If we have run-super in primary
methods should we have :around methods -- and if so, do you prefer the
name :full-shadow for this type. Ontologically this name is much
sounder, of course, if you like that kind of ontology.
-- danny
∂11-Sep-86 1532 RPG Whoppers and Ontology
∂11-Sep-86 1210 Owners-commonloopscore↑.pa@Xerox.COM Whoppers and Ontology
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Sep 86 12:10:00 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 11 SEP 86 11:43:14 PDT
Return-Path: <RPG@SAIL.STANFORD.EDU>
Redistributed: commonloopscore↑.pa
Received: from SAIL.STANFORD.EDU (SU-AI.ARPA) by Xerox.COM ; 11 SEP 86
11:42:51 PDT
Date: 11 Sep 86 11:42 PDT
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Subject: Whoppers and Ontology
To: commonloopscore↑.pa@Xerox.COM
Message-ID: <860911-114314-3067@Xerox>
Dictionaries are not usually in the business of explaining
philosophical traditions, so I'm not surprised you didn't
find a meaning you could use for `ontological.'
I have the following understanding of whoppers (what I'm about to
explain is a sketch rather than a representation of everything I understand
about them).
Suppose we have a lattice with F1 as the most general (or most basic)
flavor and F2 and F3 increasingly specific. In the flavors documentation
pictorial style, F3 would be at the top of the tree and F1 at the bottom.
In the CommonLoops pictorial style, F1 is at the bottom and F3 at the
top. Consider classical methods only, and suppose there is a whopper
defined on F1 and primary methods on F2 and F3. Suppose that the
whopper does something inconsequential and then does a continue-whopper.
Suppose that the generic function in question is applied to an instance of
F3, then I think the order of execution is the whopper first, then the
method for F3. Is this right? If I am right then Danny's comment that
whoppers are like Loops method combination and continue-whopper is like
run-super is not exactly correct, I think. Aren't whoppers and
continue-whopper like Loops method combination and run-super within the
whopper domain (if there are whoppers in the lattice, then
continue-whopper runs them in most-specific-first order), but that in the
overall order of execution, whoppers get done first then other method
types?
Moon: Is it possible in New Flavors or desirable in the Object System to
mess with the order of execution via method combination defintion (in
Flavors) or changing the disciminating function (in the Object System) so
that the user can define whopper-whoppers, which execute before whoppers?
In other words, are whoppers definable in New Flavors with whoppers
removed?
Gregor: Can you fix the Xerox re-mailer so that lines are not
broken in a funny way?
-rpg-
∂11-Sep-86 1610 RPG Re: Things on which we agree
∂11-Sep-86 1534 Owners-commonloopscore↑.pa@Xerox.COM Re: Things on which we agree
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Sep 86 15:34:49 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 11 SEP 86 14:50:50 PDT
Return-Path: <Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM>
Redistributed: commonloopscore↑.pa
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM ([192.10.41.41]) by
Xerox.COM ; 11 SEP 86 14:50:22 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 79135;
Thu 11-Sep-86 17:25:02 EDT
Date: Thu, 11 Sep 86 17:25 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Things on which we agree
To: commonloopscore↑.pa@Xerox.COM
In-Reply-To: <860911-100325-2906@Xerox>
Message-ID: <860911172500.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
[message reformatted to 70-column width to try to avoid linefolding]
Date: 11 Sep 86 10:03 PDT
From: Bobrow.pa@Xerox.COM
On this topic:
:initialize-only flag
Do we really need this feature? Why not just leave out
the :accessor if we don't want people to be able to
setf the slot? [Moon]
Presumably the :accessor option indicates that a setfable
accessor is made, while its absence still leaves (setf
(get-slot ...) ...) available? Or is GET-SLOT not
`agreed to?' If GET-SLOT exists and leaves the slot
setfable, then :initialize-only has a role. [RPG]
Hmm, if you really think get-slot should be customizable this
way, then yes, there should be a slot-option to customize it.
Never in a million years would I have figured out from the
name of the slot-option that this is what it controls, so I
think a better name should be found. Except for that, I'm
amenable to putting this in if someone thinks it's important.
[Moon]
What does ":read-only" mean in Flavors on a slot? It was my
understanding that it meant that after initialization, one
couldn't set an instance variable in a method. :initialize-only
was put in as a better name (I thought) for :read-only. Perhaps
we should drop it as a mechanism that must be supported by the
system. [Bobrow]
There is no ":read-only" feature in Flavors. There is one in
defstruct, but it doesn't tell us much since defstruct is so much
simpler. Let's drop the whole thing unless someone thinks it's
an inportant feature to have.
Whoppers (and wrappers) are different from regular methods
because they themselves control the way they get combined,
instead of being controlled by a method-combination routine
defined with define-method-combination.
This of course is how we have always done method combination in
Loops, and it has proven most useful to us. We never allowed
super classes to dictate what a subclass would do. Hence the
similarity that I saw between run-super and continue-whopper.
I'm not sure this is accurate, but I don't have anything to add beyond
what was in the other message I sent a few minutes ago.
If we have run-super in primary methods should we have :around
methods -- and if so, do you prefer the name :full-shadow for this
type. Ontologically this name is much sounder, of course, if you
like that kind of ontology.
The name :full-shadow doesn't convey much meaning to my ear.
Beyond that, I don't have much to say because I can't figure
out what the specific proposal is.
∂12-Sep-86 0805 RPG specifying metaclass etc.
∂11-Sep-86 1826 Gregor.pa@Xerox.COM specifying metaclass etc.
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Sep 86 18:26:02 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 SEP 86 18:19:01 PDT
Date: 11 Sep 86 18:18 PDT
Sender: Gregor.pa@Xerox.COM
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
Subject: specifying metaclass etc.
To: CommonLoopsCore↑.pa@Xerox.COM
cc: Gregor.pa@Xerox.COM
Line-fold: NO
Message-ID: <860911-181901-3531@Xerox>
I was wrong. It does make sense to be able to specify the class
of a class, the class of a generic-function and the class of methods
on that generic-function. For reasons which are complicated, doing
this doesn't buy as much power as it does in PCL, but it still buys
enough power to be worth doing. SO:
add a :class option to defclass
add a :class (or :generic-function-class) option to make-generic and
defgeneric
add a :method-class option to defgeneric and make-generic
∂12-Sep-86 0812 RPG Re: Defmethod syntax proposal
∂11-Sep-86 2205 Owners-CommonLoopsCore↑.PA@Xerox.COM Re: Defmethod syntax proposal
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Sep 86 22:05:24 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 11 SEP 86 22:03:45 PDT
Return-Path: <Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.PA
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM ([192.10.41.41]) by
Xerox.COM ; 11 SEP 86 22:03:31 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 79317;
Fri 12-Sep-86 01:02:26 EDT
Date: Fri, 12 Sep 86 01:02 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Defmethod syntax proposal
To: CommonLoopsCore↑.PA@Xerox.COM
In-Reply-To: <860911150805.2.GREGOR@AVALON.XEROX-PARC>
Message-ID: <860912010224.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 11 Sep 86 15:08 PDT
From: Gregor.pa@Xerox.COM
Date: Mon, 8 Sep 86 18:41 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Date: 8 Sep 86 13:13 PDT
From: Bobrow.pa@Xerox.COM
I meant that I propose that we not describe classical syntax
as part of the standard. It would simply be a backwards
compatibility feature for Flavors users.
It's really more than that; it provides conceptual compatibility for
people who are familiar with most any of the other existing
object-oriented programming languages, particularly Smalltalk-80.
It provides the familiar concepts of instance variables and "self".
Because of the widespread establishment of these concepts, I think
it's worth putting this into the standard for everyone, despite the
minor inelegance of having two syntaxes when only one is logically
necessary.
Yes, it does provide conceptual compatibility with the other existing
"object-oriented" programming languages. But I place that conceptual
compatibility in the same category as "message passing". Namely that it
is not the model we want to be emphasing to users. This new standard is
generic functions. It isn't message passing. Self and "auto-with" on
self are "message-passing" concepts not generic function concepts.
I don't think we want to be providing support in the standard for
thinking about generic functions as something that they aren't, namely
flavors/smalltalk style "message passing".
I don't agree with the idea that self and "auto-with" have something to
do with message-passing and are therefore obsolete.
Aside from that, I think we are in serious danger of falling into the
trap of trying to make a standard that contains the latest ideas that we
just thought of recently, rather than the stodgy old ideas that are
known to work but aren't any fun any more. Putting in the latest ideas
always sounds good, even to me, but historically it has almost always
resulted in bad standards or standards that aren't widely accepted or
both. Think about the things that everyone hates the most about Common
Lisp, for instance. Some of them are due to trying to be compatible
with older languages, but most of them are due to putting in new things
that seemed well thought out at the time, but in fact were not as well
thought out as we thought. Making a successful standard always includes
making compromises between desire and practice.
If we really think that only the latest ideas are any good, and everything
else should be removed from the standard, then what we are really saying
is that this is the wrong time to make a standard.
For now, the best I can come up with is to propose that it might be
enough to come up with heuristics to tell the two kinds of defmeths
apart instead of just rules. If the heuristics fail to identify the
defmeth for sure than an error would be generated or something.
I don't think anything based on heuristics is going to be acceptable as
a standard. If we have to resort to heuristics then we will be very
much better off using two different names for the two kinds of
method-defining forms.
∂12-Sep-86 1106 RPG Defmethod Syntax
∂12-Sep-86 0842 Owners-commonloopscore↑.pa@Xerox.COM Defmethod Syntax
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 12 Sep 86 08:42:35 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 12 SEP 86 08:40:17 PDT
Return-Path: <RPG@SAIL.STANFORD.EDU>
Redistributed: commonloopscore↑.pa
Received: from SAIL.STANFORD.EDU (SU-AI.ARPA) by Xerox.COM ; 12 SEP 86
08:29:28 PDT
Date: 12 Sep 86 08:29 PDT
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Subject: Defmethod Syntax
To: commonloopscore↑.pa@Xerox.COM
Message-ID: <860912-084017-4039@Xerox>
Moon makes two points. The first is that `self' and `auto-with'
form part of a larger, older tradition of OOP, and we shouldn't
ignore that tradition in order to get the `latest, most final'
ideas in the proposal. He also mentioned that he didn't think
these concepts were inextricably linked to message-passing and are
therefore obsolete.
I believe that these concepts are linked to message-passing, but
not absolutely linked. I think we ought to concentrate on finding
the right abstractions and specifying them; I don't think we should
gratuitously add features that users can implement with our abstractions
simply because `users find them useful.' On the other hand, Moon is
right that it is a mistake to opt for the latest, greatest at the
expense of well-understood concepts. We ought to consider `self'
and `auto-with' more carefully in this light. In other words,
I believe that `self' and `auto-with' are linked to message-passing,
and, even so, they might not be obsolete.
The second point is about distinguishing two forms of defmethod.
I feel it is imperative to find clear rules of distinguishing the
forms rather than invent another defmethod-like form. Only if
the possible syntactic means of distinguishing them are horrendous
should we consider proliferating functions/special forms/macros.
-rpg-
∂12-Sep-86 1108 RPG Re: Defmethod syntax proposal
∂12-Sep-86 0940 Owners-CommonLoopsCore↑.PA@Xerox.COM Re: Defmethod syntax proposal
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 12 Sep 86 09:40:26 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 12 SEP 86 09:39:22 PDT
Return-Path: <DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.PA@XEROX.ARPA
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM ([192.10.41.41]) by
Xerox.COM ; 12 SEP 86 09:08:47 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by
ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 79520;
Fri 12-Sep-86 11:56:53 EDT
Date: Fri, 12 Sep 86 11:59 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: Re: Defmethod syntax proposal
To: CommonLoopsCore↑.PA@Xerox.COM
cc: Moon@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <860912010224.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <860912115905.1.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Fri, 12 Sep 86 01:02 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
I don't agree with the idea that self and "auto-with" have something to
do with message-passing and are therefore obsolete.
Yes. The idea of New Flavors was to get rid of "message passing" and
instead go to "generic functions". We did that, and New Flavors still
has "self" and "auto-with" even though it has "generic functions"
instead of "message passing". Rather, "self" and "auto-with" are
associated with having generic functions with only one argument that's
discriminated on. What makes them go away is not "generic functions",
but "multimethods".
It seems to me that you folks are worried that providing the
"traditional" syntax will discourage users from taking advantage of the
greater power provided by the multimethod capability of the new spec. I
believe that we can take care of this by the organization and phrasing
of the documentation of the spec. We can make it clear that the
"traditional" syntax is stricly weaker than the "modern" syntax, and has
no additional capabilities, and is being provided because the style is
well-known and traditional, rather than because it's considered to be
"better" in any interesting sense.
∂12-Sep-86 1245 RPG Re: Defmethod syntax proposal
∂11-Sep-86 1535 Owners-CommonLoopsCore↑.PA@Xerox.COM Re: Defmethod syntax proposal
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Sep 86 15:35:13 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 11 SEP 86 15:10:52 PDT
Redistributed: CommonLoopsCore↑.PA@XEROX.ARPA
Received: from Semillon.ms by ArpaGateway.ms ; 11 SEP 86 15:10:18 PDT
Date: Thu, 11 Sep 86 15:08 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: Defmethod syntax proposal
To: DLW@ALDERAAN.SCRC.Symbolics.COM, Bobrow.pa@Xerox.COM,
Moon@STONY-BROOK.SCRC.Symbolics.COM, CommonLoopsCore↑.PA@Xerox.COM
In-Reply-To: <860908223153.1.DLW@CHICOPEE.SCRC.Symbolics.COM>,
The message of 8 Sep 86 16:13-PDT from Bobrow.pa,
<860908184131.4.DLW@CHICOPEE.SCRC.Symbolics.COM>,
The message of 8 Sep 86 13:13-PDT from Bobrow.pa,
<860908125848.1.MOON@EUPHRATES.SCRC.Symbolics.COM>,
The message of 8 Sep 86 09:10-PDT from Bobrow.pa,
<860905205118.7.MOON@EUPHRATES.SCRC.Symbolics.COM>,
<860904180145.6.MOON@EUPHRATES.SCRC.Symbolics.COM>,
The message of 5 Sep 86 10:52-PDT from Bobrow.pa,
The message of 4 Sep 86 13:38-PDT from Bobrow.pa,
<860904150145.7.MOON@EUPHRATES.SCRC.Symbolics.COM>,
The message of 3 Sep 86 18:03-PDT from Bobrow.pa,
<860902235003.8.MOON@EUPHRATES.SCRC.Symbolics.COM>,
<860903004049.0.DLW@CHICOPEE.SCRC.Symbolics.COM>,
<860903004113.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <860911150805.2.GREGOR@AVALON.XEROX-PARC>
Line-fold: no
I think I have digested all the mail on this topic.
Date: 3 Sep 86 18:03 PDT
From: Bobrow.pa
3) :discriminator-class (now called :generic-function-class) and
:method-class are not options of defmethod. They are (advanced)
options of defgeneric.
:discriminator-class and :method-class are not features of defgeneric.
For the same reasons that the :class argument to defclass no longer
exists, these no longer exist.
Date: 8 Sep 86 09:10 PDT
From: Bobrow.pa
In "classical" syntax, no argument of lambda-list can be type
specified. In general syntax at least one must be specifed if
you are using method combination options.
Date: Mon, 8 Sep 86 12:58 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
I don't see why method combination options would be disallowed
for default methods. If it doesn't make sense to allow such
options for default methods, then we can go back to that proposal.
I think it makes perfect sense to have method combination options on
default methods. A :around default method is the canonical example.
Date: Mon, 8 Sep 86 18:41 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Date: 8 Sep 86 13:13 PDT
From: Bobrow.pa@Xerox.COM
I meant that I propose that we not describe classical syntax
as part of the standard. It would simply be a backwards
compatibility feature for Flavors users.
It's really more than that; it provides conceptual compatibility for
people who are familiar with most any of the other existing
object-oriented programming languages, particularly Smalltalk-80.
It provides the familiar concepts of instance variables and "self".
Because of the widespread establishment of these concepts, I think
it's worth putting this into the standard for everyone, despite the
minor inelegance of having two syntaxes when only one is logically
necessary.
Yes, it does provide conceptual compatibility with the other existing
"object-oriented" programming languages. But I place that conceptual
compatibility in the same category as "message passing". Namely that it
is not the model we want to be emphasing to users. This new standard is
generic functions. It isn't message passing. Self and "auto-with" on
self are "message-passing" concepts not generic function concepts.
I don't think we want to be providing support in the standard for
thinking about generic functions as something that they aren't, namely
flavors/smalltalk style "message passing".
I do think we should be providing support in the standard so that an
environment which supports flavors as well as the standard can only have
one defmethod symbol and can unamiguosly determine whether or or not the
defmethod is a flavors defmethod or a CLOS defmethod. I used to think
that was easy until I realized that this also had to work for the kinds
of defmethods that people are going to write using release 7 too.
For now, the best I can come up with is to propose that it might be
enough to come up with heuristics to tell the two kinds of defmeths
apart instead of just rules. If the heuristics fail to identify the
defmeth for sure than an error would be generated or something. Because
I can't figure out how often the heuristics I had in mind might fail I
thought I would send them out to get your all's opinion:
use the name-and-options-syntax:
(defmethod name-and-options args . body)
and used the heuristics:
1. name-and-options is a symbol --> its CLOS for sure
2. one or more of the "required" args is a list --> CLOS for sure
3. cadr of name-and-options is name of a flavor --> probably Flavors
there might be other good rules too.
-------
∂12-Sep-86 1248 RPG Whoppers and Phenomenology
∂11-Sep-86 1534 Owners-commonloopscore↑.pa@Xerox.COM Whoppers and Phenomenology
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Sep 86 15:34:39 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 11 SEP 86 14:40:41 PDT
Return-Path: <Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM>
Redistributed: commonloopscore↑.pa
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM ([192.10.41.41]) by
Xerox.COM ; 11 SEP 86 14:40:16 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 79120;
Thu 11-Sep-86 17:14:47 EDT
Date: Thu, 11 Sep 86 17:14 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Whoppers and Phenomenology
To: commonloopscore↑.pa@Xerox.COM
In-Reply-To: <860911-114314-3067@Xerox>
Message-ID: <860911171444.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 11 Sep 86 11:42 PDT
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
I have the following understanding of whoppers (what I'm about to
explain is a sketch rather than a representation of everything I understand
about them).
Suppose we have a lattice with F1 as the most general (or most basic)
flavor and F2 and F3 increasingly specific. In the flavors documentation
pictorial style, F3 would be at the top of the tree and F1 at the bottom.
In the CommonLoops pictorial style, F1 is at the bottom and F3 at the
top. Consider classical methods only, and suppose there is a whopper
defined on F1 and primary methods on F2 and F3. Suppose that the
whopper does something inconsequential and then does a continue-whopper.
Suppose that the generic function in question is applied to an instance of
F3, then I think the order of execution is the whopper first, then the
method for F3. Is this right?
Right.
If I am right then Danny's comment that
whoppers are like Loops method combination and continue-whopper is like
run-super is not exactly correct, I think. Aren't whoppers and
continue-whopper like Loops method combination and run-super within the
whopper domain (if there are whoppers in the lattice, then
continue-whopper runs them in most-specific-first order), but that in the
overall order of execution, whoppers get done first then other method
types?
That's right. If you use only whoppers then you can use continue-whopper
and get the same control structure as if you had used only Loops methods
and used run-super.
If on the other hand you have both whoppers and ordinary methods (of
whatever type, primary, :before, or whatever), then all the whoppers get
control before any of the ordinary methods. Another way of saying the
same thing is that in any given whopper all of the ordinary methods,
regardless of how specific the flavor they are attached to, are "inside
of" continue-whopper (along with the whoppers on less specific flavors).
Moon: Is it possible in New Flavors or desirable in the Object System to
mess with the order of execution via method combination defintion (in
Flavors) or changing the disciminating function (in the Object System) so
that the user can define whopper-whoppers, which execute before whoppers?
In other words, are whoppers definable in New Flavors with whoppers
removed?
I think these are two (no, three, maybe four) different questions. Let
me try to answer them separately.
I assume that in Common Lisp with objects the discriminator has control
at some level over whoppers and the user could replace or augment them
by redefining a few methods. I think the discriminator class operates
at a different level of modularity than the method-combination type,
and that it's good for both of these features to exist.
In Flavors, define-method-combination has no control whatsoever over
defwhoppers; they're handled separately.
In Flavors, the user could define a method-combination type that
understood methods with a particular method-option to behave just like
whoppers, or similarly to whoppers but with some modification such as
whopper-whoppers. These couldn't be defined with the existing
defwhopper macro, since define-method-combination has no control over
those. To make those neo-whoppers work with every method-combination
would require modifying every define-method-combination to know about
them. Other than that it's extremely easy.
It's been proposed several times over the years to extend Flavors
whoppers to give the programmer more control over their ordering than
just having the most-specific ones first. None of the proposals ever
got implemented.
Interfaces exist by which the user of New Flavors could define
whopper-whoppers, which execute before regular whoppers, without having
to replace regular whoppers with neo-whoppers. The implementation of
whoppers is in fact table-driven or object-oriented or whatever you want
to call it. However, these interfaces aren't documented and are likely
to change as a result of the project we are currently all engaged in.
∂12-Sep-86 1545 RPG ordering of defclasses
∂12-Sep-86 1416 Gregor.pa@Xerox.COM ordering of defclasses
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 12 Sep 86 14:14:40 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 12 SEP 86 13:11:48 PDT
Date: Fri, 12 Sep 86 13:09 PDT
From: Gregor.pa@Xerox.COM
Subject: ordering of defclasses
To: CommonLoopsCore↑.pa@Xerox.COM
Message-ID: <860912130952.1.GREGOR@AVALON.XEROX-PARC>
Line-fold: no
In seperate messages, I am going to send out some general comments about
the current draft of the West Coast spec. I am sending these to the
entire list even though I realize that the east coast people haven't
seen this spec, and that they aren't happy about this.
I have been assured that the legal problems with sending the spec to the
east coast have now all been fixed. They weren't big problems, no-one
questions that the spec should be distributed, its just that someone far
from here had to be reminded why they should sign the release ("in my
left hand you see the release form, in my right hand you see a
Louisville Slugger... pick a hand, any hand").
-- Currently the spec makes no statement about when all the included
classes of a class must be defined:
1. They must be defined before the defclass is evaluated. PCL does
this now. I don't like this it makes it harder to order loading of
files for no good reason.
2. They must be defined before an instance of the class is created.
This is what flavors does now and is what I think we should do. It
takes only a very little bit of implementation overhead and provides the
user with nice convenience.
So, these two rules should be added to the spec:
All the classes in the included classes tree of a class must be defined
before it is legal to make an instance of the class.
A class must be defined before it can be mentioned as an argument
specifier in a defmethod.
-------
∂12-Sep-86 1657 RPG Re: Defmethod syntax proposal
∂12-Sep-86 1309 Gregor.pa@Xerox.COM Re: Defmethod syntax proposal
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 12 Sep 86 13:08:57 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 12 SEP 86 12:50:49 PDT
Date: 12 Sep 86 12:48 PDT
Sender: Gregor.pa@Xerox.COM
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
Subject: Re: Defmethod syntax proposal
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Fri, 12 Sep 86 01:02 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CommonLoopsCore↑.PA@Xerox.COM
Message-ID: <860912-125049-4322@Xerox>
Date: Fri, 12 Sep 86 01:02 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Aside from that, I think we are in serious danger of falling into the
trap of trying to make a standard that contains the latest ideas that we
just thought of recently, rather than the stodgy old ideas that are
known to work but aren't any fun any more ...
... Think about the things that everyone hates the most about Common
Lisp, for instance.
I agree.
If we really think that only the latest ideas are any good, and
everything else should be removed from the standard.
We don't.
I don't think anything based on heuristics is going to be acceptable as
a standard.
Of course, but I wasn't suggesting it as part of the standard. Because I believe
that the classical defmethod has no place in the standard, I was only suggesting
that we should craft the standard in such that in your environment, it should be
possible to distinguish a flavors defmethod from a standard one.
Date: 12 Sep 86 08:29 PDT
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
I think we ought to concentrate on finding
the right abstractions and specifying them
I claim that we have. One abstraction is defining a method; that is done with
defmethod. Another abstraction is defining a lexical context in which the slots
of an object can be accessed as if they were variables; that is done with with.
Date: Fri, 12 Sep 86 11:59 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Yes. The idea of New Flavors was to get rid of "message passing" and
instead go to "generic functions". We did that, and New Flavors still
has "self" and "auto-with" even though it has "generic functions"
instead of "message passing".
Frankly, I claim that is an inelegance in the design of new flavors.
What makes them go away is not "generic functions",
but "multimethods".
No, I think that generic functions makes them go away. What multimethods
do is make it clear that generic functions should make self and auto-with go
away. Multimethods, being the general case of generic functions make it
clear that it is wrong to think of any single distinguished argument to a
generic function as somehow having a greater status than the others.
It seems to me that you folks are worried that providing the
"traditional" syntax will discourage users from taking advantage of the
greater power provided by the multimethod capability of the new spec. I
believe that we can take care of this by the organization and phrasing
of the documentation of the spec.
I agree that documentation can go a long way towards making it clear that
classical defmethod syntax is an abbreviation for a defmethod and a with.
But I don't think we are worried about what you suggest we are. I frankly
think that extending the behavior of the standard defmeth so that it does
auto-with is conceptually in-elegant.
But I agree that it provides a convenience that many people have grown
used to. So, given appropriate documentation, and a design for arguments
to defmethod which is nice, I might be willing to concede on this issue. But
I suspect that we are going to have to go to having to seperate names for
these things, which is where we were two weeks ago (but they were the
wrong names).
∂12-Sep-86 1752 RPG ordering of defclasses
∂12-Sep-86 1701 Owners-CommonLoopsCore↑.pa@Xerox.COM ordering of defclasses
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 12 Sep 86 17:01:03 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 12 SEP 86 14:35:40 PDT
Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.pa@XEROX.ARPA
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
Xerox.COM ; 12 SEP 86 14:23:33 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 102194; Fri
12-Sep-86 17:22:45 EDT
Date: Fri, 12 Sep 86 17:22 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: ordering of defclasses
To: CommonLoopsCore↑.pa@Xerox.COM
In-Reply-To: <860912130952.1.GREGOR@AVALON.XEROX-PARC>
Message-ID: <860912172209.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 12 Sep 86 13:09 PDT
From: Gregor.pa@Xerox.COM
Currently the spec makes no statement about when all the included
classes of a class must be defined:
1. They must be defined before the defclass is evaluated. PCL does
this now. I don't like this it makes it harder to order loading of
files for no good reason.
2. They must be defined before an instance of the class is created.
This is what flavors does now and is what I think we should do. It
takes only a very little bit of implementation overhead and provides the
user with nice convenience.
So, these two rules should be added to the spec:
All the classes in the included classes tree of a class must be defined
before it is legal to make an instance of the class.
A class must be defined before it can be mentioned as an argument
specifier in a defmethod.
Flavors in fact requires that all of the component flavors must be
defined before you can do a defmethod. I believe the reason for this
applies to Common Lisp Classes as well, and would translate into a third
rule:
All the classes in the included classes tree of a class must be
defined (known to the compiler) before it is legal to
evaluate (compile) a WITH.
With this addition, I agree.
∂12-Sep-86 1756 RPG Getting together to work
∂12-Sep-86 1701 Owners-CommonLoopsCore↑.pa@Xerox.COM Getting together to work
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 12 Sep 86 17:00:00 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 12 SEP 86 13:31:52 PDT
Return-Path: <Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.pa
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM ([192.10.41.41]) by
Xerox.COM ; 12 SEP 86 13:06:28 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 79640;
Fri 12-Sep-86 14:34:31 EDT
Date: Fri, 12 Sep 86 14:34 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Getting together to work
To: CommonLoopsCore↑.pa@Xerox.COM
In-Reply-To: <860910-154308-2286@Xerox>
Message-ID: <860912143428.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 10 Sep 86 15:42 PDT
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
We had made a plan to get together monday moring at OOPSLA and work on
the spec. I believe that we will have more work to do than can be done
in three hours.
Instead, I propose that we get together Friday and Saturday after OOPSLA
in Palo Alto. This will give us enough time to actually get some work
done, and takes advantage of existing travel to get a lot of people in
the same place.
I talked about this with Dan and Sonya. We agree that we need a face to face
meeting, but we're not sure about the timing. We all think it would be better
to have the meeting before OOPSLA rather than after, so that at OOPSLA we are
all telling the same story to people we talk to. Also we promised at the Lisp
conference that we would hand something out at OOPSLA showing our progress,
and it seems like a good idea to have a face to face meeting to finalize what
goes into that document.
If we're going to meet before OOPSLA there are some constraints. Dan is not
available until the 24th. Dan and I are not available on the 26th. Sonya
can't really spend a whole week away from the office. There seem to be several
possibilities:
Meet on the weekend Sep 27-28, or just Sep 28, either in Palo Alto or in
Portland. It's probably possible for us to fly out Friday night, but
obviously a one-day meeting would be a little easier logistically than a
two-day meeting. I don't know if one day is enough.
Meet on Thursday Sep 25 either in Cambridge or in Washington (this is the day
after the X3J13 meeting).
We also need to start talking through the mail about what excatly we're going
to have ready to hand out to the public at OOPSLA.
I propose that we use the Monday morning at OOPSLA time to have a more
open meeting with people from LMI and HP.
This sounds good.
∂13-Sep-86 2051 RPG Defmethod syntax
∂12-Sep-86 2126 Owners-CommonLoopsCore↑.PA@Xerox.COM Defmethod syntax
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 12 Sep 86 21:26:06 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 12 SEP 86 21:24:12 PDT
Return-Path: <Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.PA
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM ([192.10.41.41]) by
Xerox.COM ; 12 SEP 86 21:23:51 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 79829;
Sat 13-Sep-86 00:22:32 EDT
Date: Sat, 13 Sep 86 00:22 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Defmethod syntax
To: CommonLoopsCore↑.PA@Xerox.COM
Message-ID: <860913002227.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
I've read all the mail on this again and I'd like to try to converge
on something that we can all agree on. This message is an attempt to
lay out all the issues without including any advocacy.
I think we can decide on the syntax of defmethod independent of issues
of discriminating on optional arguments, whether defgeneric is required
or optional, the abbreviated form of WITH that Danny Bobrow mentioned
(discussed in a separate message), and whether the syntax for classical
methods is a required or optional part of the standard. (The syntax for
classical methods has to be provided for in some form in order to meet
the goal of migration through mechanical translation that we set for
ourselves last month, as you recall.)
I see three viable proposals. I will give each proposal in the BNF
variant explained on page 8 of Common Lisp: the Language, except that
lowercase means italics and uppercase means roman, along with six
examples (the first lines of the same six methods for each). The six
examples are: a multimethod without options; a multimethod with an
option; a default method without options; a default method with an
option; a classical method without options; and a classical method with
an option.
Each proposal actually comes in (a) and (b) forms, depending on what we
do about SETF. That's discussed after the basic proposals. Definitions
of nonterminal symbols are at the end of this message, so they don't
get in the way.
THREE VIABLE PROPOSALS:
(1) Unparenthesized Options
General syntax:
(DEFMETHOD generic-function {option}*
{lambda-list | qualified-lambda-list}
{declaration | doc-string}*
{form}*)
Classical syntax:
(DEFMETHOD (generic-function self-class {option}*)
{lambda-list | qualified-lambda-list}
{declaration | doc-string}*
{form}*)
(defmethod foo ((a c1) (b c2))
(defmethod foo :before ((a c1) (b c2))
(defmethod foo (a b)
(defmethod foo :before (a b)
(defmethod (foo c1) (b)
(defmethod (foo c1 :before) (b)
(2) Untyped Arglist
General syntax:
(DEFMETHOD generic-function
{lambda-list | qualified-lambda-list}
{declaration | doc-string}*
{form}*)
and
(DEFMETHOD (generic-function {option}*)
qualified-lambda-list
{declaration | doc-string}*
{form}*)
Classical syntax:
(DEFMETHOD (generic-function self-class {option}*)
lambda-list
{declaration | doc-string}*
{form}*)
(defmethod foo ((a c1) (b c2))
(defmethod (foo :before) ((a c1) (b c2))
(defmethod foo (a b)
(defmethod (foo :before) ((a t) b)
(defmethod (foo c1) (b)
(defmethod (foo c1 :before) (b)
(3) Two Names
General syntax:
(DEFINE-METHOD generic-function
{lambda-list | qualified-lambda-list}
{declaration | doc-string}*
{form}*)
and
(DEFINE-METHOD (generic-function {option}*)
{lambda-list | qualified-lambda-list}
{declaration | doc-string}*
{form}*)
Classical syntax:
(DEFMETHOD (generic-function self-class {option}*)
{lambda-list | qualified-lambda-list}
{declaration | doc-string}*
{form}*)
(define-method foo ((a c1) (b c2))
(define-method (foo :before) ((a c1) (b c2))
(define-method foo (a b)
(define-method (foo :before) (a b)
(defmethod (foo c1) (b)
(defmethod (foo c1 :before) (b)
SETF VARIANTS:
There are two different ways to add the ability to define methods for
SETF of a generic function to each proposal:
(a) Tack -SETF onto the special form name.
(b) Replace generic-function with (SETF generic-function).
In both variants, a setf-lambda-list is inserted between the regular
lambda-list and the {declaration | doc-string}* that begins the body.
DRAWBACKS OF EACH PROPOSAL:
(1) lambda-list is not always the second subform of DEFMETHOD.
(2) In general syntax, you cannot use options without having a
qualified-lambda-list rather than a plain lambda-list. In other
words, a default daemon method has to have an extra t in it.
Classical syntax cannot be used to write multi-methods.
Classical syntax is a bit harder to identify at a glance,
although it's not syntactically ambiguous.
(3) Twice as many special forms.
(a) Twice as many special forms. Need DEFGENERIC-SETF, too.
(b) Funny syntax, SETF in the car of a list means something different
from other symbols in the car of a list, i.e. the cdr of the list is not
{option}*. Also SETF in the generic function changes the parsing of the
rest of the defmethod.
NONTERMINALS:
generic-function -- a symbol that names the generic function
being specialized.
self-class -- a symbol that names the class of the first argument.
option -- a non-nil symbol or a number, used by method
combination to identify the method.
lambda-list -- as defined in CLtL p.60.
qualified-lambda-list -- a lambda-list with at least one
variable replaced by a type-qualified variable
so that discrimination occurs on that argument.
setf-lambda-list -- {lambda-list | qualified-lambda-list}
except that for now there can be only one parameter.
declaration, doc-string, form -- as defined in CLtL.
∂13-Sep-86 2100 RPG abbreviated form of WITH
∂12-Sep-86 2131 Owners-CommonLoopsCore↑.PA@Xerox.COM abbreviated form of WITH
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 12 Sep 86 21:31:41 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 12 SEP 86 21:30:40 PDT
Return-Path: <Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.PA
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM ([192.10.41.41]) by
Xerox.COM ; 12 SEP 86 21:30:21 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 79830;
Sat 13-Sep-86 00:28:43 EDT
Date: Sat, 13 Sep 86 00:28 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: abbreviated form of WITH
To: CommonLoopsCore↑.PA@Xerox.COM
Message-ID: <860913002840.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Elaborating on something Danny Bobrow mentioned, it would be possible
to extend the syntax of argument qualifications to provide an automatic
WITH. The optional prefix-name and type-name arguments to WITH should
be optionally specifiable. This syntax can be used on more than one
argument, but the program is invalid if there are any name conflicts,
just as in LET and just as in WITH with more one name-specification.
This seems like a good idea. There are several ways it could be done,
let me try and propose some. The syntax is the syntax for a
discriminating parameter specifier, in the BNF variant explained on page
8 of Common Lisp: the Language, except that lowercase means italics and
uppercase means roman.
(1) (variable class :WITH-VARS [prefix-name [type-name]])
(2) (variable :INSIDE class [prefix-name [type-name]])
(3) (variable class :WITH T [:PREFIX prefix-name] [:CLASS type-name])
(4) (variable :CLASS class :WITH T [:PREFIX prefix-name])
In all of these, the meaning of (variable class) is not changed.
You who are reading this will probably come up with some better ideas.
∂13-Sep-86 2101 RPG Re: Defmethod syntax
∂13-Sep-86 1550 Masinter.pa@Xerox.COM Re: Defmethod syntax
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 13 Sep 86 15:50:29 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 13 SEP 86 10:50:44 PDT
Date: 13 Sep 86 10:51 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Defmethod syntax
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Sat, 13 Sep 86 00:22 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CommonLoopsCore↑.PA@Xerox.COM
Message-ID: <860913-105044-4936@Xerox>
(4) two other names:
General syntax:
(DEFMETHOD {generic-function | (generic-function {option}*)}
{lambda-list | qualified-lambda-list}
{declaration | doc-string}*
{form}*)
(This combines the forms of your (2), and is upward compatible with DEFUN)
and
Classical syntax:
(DEFINE-CLASSICAL-METHOD (generic-function self-class {option}*)
lambda-list
{declaration | doc-string}*
{form}*)
∂14-Sep-86 1112 Gregor.pa@Xerox.COM Re: Getting together to work
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 14 Sep 86 11:12:35 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 14 SEP 86 11:11:21 PDT
Date: 14 Sep 86 11:11 PDT
Sender: Gregor.pa@Xerox.COM
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
Subject: Re: Getting together to work
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Fri, 12 Sep 86 14:34 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CommonLoopsCore↑.pa@Xerox.COM
Message-ID: <860914-111121-5339@Xerox>
Danny can't make it anytime between Washington and Oopsla.
DLW can't make it until the 24th.
During Washington or OOPSLA there isn't enough time (or peace and quiet).
In your message, you say "Sonya can't really spend a whole week away
from the office." Does this mean that Sonya can't make it after OOPSLA
(because she is going to OOPSLA)?
If in fact Sonya can't make it right after OOPSLA then I don't see any way
that we are going to be able to take advantage of the travel we are going to
be making anyways to get together. But I do think we should get together
real soon. Would you all be interested in coming out here the week after
OOPSLA?
∂14-Sep-86 1118 Owners-CommonLoopsCore↑.pa@Xerox.COM Re: ordering of defclasses
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 14 Sep 86 11:18:26 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 14 SEP 86 11:14:41 PDT
Redistributed: CommonLoopsCore↑.pa
Received: from Cabernet.ms by ArpaGateway.ms ; 14 SEP 86 11:14:27 PDT
Date: 14 Sep 86 11:14 PDT
Sender: Gregor.pa@Xerox.COM
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
Subject: Re: ordering of defclasses
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Fri, 12 Sep 86 17:22 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CommonLoopsCore↑.pa@Xerox.COM
Message-ID: <860914-111441-5341@Xerox>
Date: Fri, 12 Sep 86 17:22 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Flavors in fact requires that all of the component flavors must be
defined before you can do a defmethod. I believe the reason for this
applies to Common Lisp Classes as well, and would translate into a third
rule:
All the classes in the included classes tree of a class must be
defined (known to the compiler) before it is legal to
evaluate (compile) a WITH.
With this addition, I agree.
Right.
∂14-Sep-86 1622 Gregor.pa@Xerox.COM Method Naming and Identity Proposal
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 14 Sep 86 16:22:34 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 14 SEP 86 16:11:31 PDT
Date: Sun, 14 Sep 86 16:10 PDT
From: Gregor.pa@Xerox.COM
Subject: Method Naming and Identity Proposal
To: Moon@STONY-BROOK.SCRC.Symbolics.COM, CommonLoopsCore↑.PA@Xerox.COM
In-Reply-To: <860902233747.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <860914161007.3.GREGOR@AVALON.XEROX-PARC>
Line-fold: no
I am not sure what you mean by making the concept of the names and
identities of methods precise. Or what it is about the identities of
methods you want to specify.
Is this just for portable environment features like TRACE? If so then I
agree that we need to specify a way to tell trace to trace a particular
method, but I don't believe we need to specify the kind of functionality
that comes to mind when I think of method names.
-------
∂14-Sep-86 1817 Gregor.pa@Xerox.COM default optional arguments to a generic function
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 14 Sep 86 18:16:59 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 14 SEP 86 18:06:04 PDT
Date: Sun, 14 Sep 86 18:04 PDT
From: Gregor.pa@Xerox.COM
Subject: default optional arguments to a generic function
To: CommonLoopsCore↑.pa@Xerox.COM
Message-ID: <860914180428.4.GREGOR@AVALON.XEROX-PARC>
Line-fold: no
For clarity, this message assumes that you have to do a defgeneric
before a defmethod. I don't want to make up my mind about having to do
a defgeneric before a defmethod until I understand this issue of
defaulting optional arguments.
I have tried to process all the preceding mail on this subject. Forgive
me if I have just re-iterated an existing position.
As terminology:
GENERIC FUNCTION DEFAULTING is when the generic function proper
provides default values for optional arguments to the generic
function. In the kind of generic function defaulting I am talking
about, the defaulted values are used as part of the method lookup
and passed on to whichever method is invoked.
METHOD DEFAULTING is when a particular method provides default
values for some of its arguments.
In this variant of generic function defaulting, it signals an error to
attempt to define a method on a generic function which accepts less than
the number of arguments that the generic function defaulting can
produce. Here is an example:
(defgeneric draw (thing place &optional (clip-mask *clip-mask*)) ..)
This defmethod is legal:
(defgeneric draw ((thing block) (place window) clip-mask) ..)
But this defmethod is not:
(defgeneric draw ((thing block) (place window)) ..)
Moon's variant of generic function defaulting, in which the defaulted
values are dropped on the floor after method lookup does not have this
problem. Each method must accept only as many required arguments as the
generic function proper.
So, I see two different schemes for generic function defaulting:
GFD #1. the defaults from the defgeneric are used only for method
lookup. This is the kind I described above.
GFD #2. the defaults from the defgeneric are used for method lookup
and also passed to the method.
There is a fundamental conceptual difference here. I am not sure which
I prefer, but I am leaning towards number 1. Because...
Date: Thu, 4 Sep 86 16:15 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
(make-specializable 'print)
This is the same as:
(defgeneric print (object &optional stream))
(defmethod print (x &optional ((stream gee-whiz-display))) ...)
But (let ((*standard-output* <instance of the gee-whiz-display>))
(print <lisp-object>))
calls the wrong method! This is what I have been complaining about all
along. This is the key issue.
I agree that this is the key issue. Using GFD #1, there is no problem.
You would have to specify a default value for the second argument to the
PRINT generic function as a whole:
(defgeneric print (object &optional (stream *standard-output*))
Then the example:
(let ((*standard-output* <instance of the gee-whiz-display>))
(print <lisp-object>))
would get the right method.
-------
∂14-Sep-86 1837 Owners-commonloopscore↑.pa@Xerox.COM Method Identification
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 14 Sep 86 18:37:23 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 14 SEP 86 18:32:19 PDT
Return-Path: <RPG@SAIL.STANFORD.EDU>
Redistributed: commonloopscore↑.pa
Received: from SAIL.STANFORD.EDU (SU-AI.ARPA) by Xerox.COM ; 14 SEP 86
18:32:09 PDT
Date: 14 Sep 86 18:31 PDT
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Subject: Method Identification
To: commonloopscore↑.pa@Xerox.COM
Message-ID: <860914-183219-5434@Xerox>
Presumably a method is identified by the pair of its generic function
and its argument signature (the classes of the arguments). Also,
presumably, the function FIND-METHOD uses this pair.
-rpg-
------- End undelivered message -------
∂15-Sep-86 1152 Owners-commonloopscore↑.pa@Xerox.COM Method Identification
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Sep 86 11:52:02 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 15 SEP 86 10:38:36 PDT
Return-Path: <Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM>
Redistributed: commonloopscore↑.pa
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM ([192.10.41.41]) by
Xerox.COM ; 15 SEP 86 10:37:26 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 80351;
Mon 15-Sep-86 13:34:06 EDT
Date: Mon, 15 Sep 86 13:34 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Method Identification
To: commonloopscore↑.pa@Xerox.COM
In-Reply-To: <860914-183219-5434@Xerox>
Message-ID: <860915133401.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 14 Sep 86 18:31 PDT
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Presumably a method is identified by the pair of its generic function
and its argument signature (the classes of the arguments). Also,
presumably, the function FIND-METHOD uses this pair.
You forgot some things, such as the method-options. This was discussed
extensively in my message of 2 Sep 86, message ID
<860902233747.7.MOON@EUPHRATES.SCRC.Symbolics.COM>.
∂15-Sep-86 1152 Owners-CommonLoopsCore↑.PA@Xerox.COM Re: Defmethod syntax
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Sep 86 11:52:11 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 15 SEP 86 10:42:43 PDT
Return-Path: <Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.PA
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM ([192.10.41.41]) by
Xerox.COM ; 15 SEP 86 10:38:41 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 80355;
Mon 15-Sep-86 13:37:12 EDT
Date: Mon, 15 Sep 86 13:37 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Defmethod syntax
To: CommonLoopsCore↑.PA@Xerox.COM
In-Reply-To: <860913-105044-4936@Xerox>
Message-ID: <860915133708.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 13 Sep 86 10:51 PDT
From: Masinter.pa@Xerox.COM
(4) two other names:
General syntax:
(DEFMETHOD {generic-function | (generic-function {option}*)}
{lambda-list | qualified-lambda-list}
{declaration | doc-string}*
{form}*)
(This combines the forms of your (2), and is upward compatible with DEFUN)
and
Classical syntax:
(DEFINE-CLASSICAL-METHOD (generic-function self-class {option}*)
lambda-list
{declaration | doc-string}*
{form}*)
This would be fine except that it violates the goal we set for ourselves
last month of providing smooth migration paths for existing users of
Flavors and Portable Common Loops. Since you can't tell a new-style
DEFMETHOD from a Flavors DEFMETHOD, it would be impossible to provide
incremental mechanical translation. I don't think we should contemplate
abandoning that goal without a more compelling reason than merely liking
the spelling DEFMETHOD more than any other.
∂15-Sep-86 1152 Owners-CommonLoopsCore↑.PA@Xerox.COM Method Naming and Identity Proposal
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Sep 86 11:52:27 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 15 SEP 86 10:48:48 PDT
Return-Path: <Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.PA
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM ([192.10.41.41]) by
Xerox.COM ; 15 SEP 86 10:44:48 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 80362;
Mon 15-Sep-86 13:43:29 EDT
Date: Mon, 15 Sep 86 13:43 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Method Naming and Identity Proposal
To: CommonLoopsCore↑.PA@Xerox.COM
In-Reply-To: <860914161007.3.GREGOR@AVALON.XEROX-PARC>
Message-ID: <860915134324.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: Sun, 14 Sep 86 16:10 PDT
From: Gregor.pa@Xerox.COM
I am not sure what you mean by making the concept of the names and
identities of methods precise. Or what it is about the identities of
methods you want to specify.
To quote from my message of 2 Sep, which your message is a reply to:
"The key property of these names is that when two defmethod forms with the same
name (according to the EQUAL function) are evaluated, the second defmethod
replaces the method defined by the first defmethod, rather than defining a
second method."
Is this just for portable environment features like TRACE?
What would be needed for TRACE is a further extension, not merely making the
concept of method identity precise, but also reifying it as a Lisp
object that can be used as the method's name in the arguments to TRACE.
I wasn't proposing that, since it seems to be leaving the area of object
oriented programming and getting into other parts of the Common Lisp
specification. To quote again from my message:
"In an implementation that has function-specs, these lists can be used as
function-specs to access the method's definition, trace it, and so forth.
In other implementations I guess there is no way to perform those operations."
In other words, I'm not proposing to require every implementation to have
function-specs (I would certainly like to, but not as part of the
object-oriented programming proposal).
I think I should have been clearer about what I meant by an identity and
what I meant by a name. If the above hasn't clarified it, let me know and
I'll work harder on it.
If so then I
agree that we need to specify a way to tell trace to trace a particular
method, but I don't believe we need to specify the kind of functionality
that comes to mind when I think of method names.
What functionality is that?
∂15-Sep-86 1437 Owners-CommonLoopsCore↑.pa@Xerox.COM default optional arguments to a generic function
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Sep 86 14:34:39 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 15 SEP 86 12:26:13 PDT
Return-Path: <Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.pa
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM ([192.10.41.41]) by
Xerox.COM ; 15 SEP 86 12:25:35 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 80419;
Mon 15-Sep-86 15:24:38 EDT
Date: Mon, 15 Sep 86 15:24 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: default optional arguments to a generic function
To: CommonLoopsCore↑.pa@Xerox.COM
In-Reply-To: <860914180428.4.GREGOR@AVALON.XEROX-PARC>
Message-ID: <860915152433.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: Sun, 14 Sep 86 18:04 PDT
From: Gregor.pa@Xerox.COM
For clarity, this message assumes that you have to do a defgeneric
before a defmethod. I don't want to make up my mind about having to do
a defgeneric before a defmethod until I understand this issue of
defaulting optional arguments.
I have tried to process all the preceding mail on this subject. Forgive
me if I have just re-iterated an existing position.
As terminology:
GENERIC FUNCTION DEFAULTING is when the generic function proper
provides default values for optional arguments to the generic
function. In the kind of generic function defaulting I am talking
about, the defaulted values are used as part of the method lookup
and passed on to whichever method is invoked.
METHOD DEFAULTING is when a particular method provides default
values for some of its arguments.
In this variant of generic function defaulting, it signals an error to
attempt to define a method on a generic function which accepts less than
the number of arguments that the generic function defaulting can
produce. Here is an example:
(defgeneric draw (thing place &optional (clip-mask *clip-mask*)) ..)
This defmethod is legal:
(defgeneric draw ((thing block) (place window) clip-mask) ..)
But this defmethod is not:
(defgeneric draw ((thing block) (place window)) ..)
Moon's variant of generic function defaulting, in which the defaulted
values are dropped on the floor after method lookup does not have this
problem. Each method must accept only as many required arguments as the
generic function proper.
In my proposal of 2 September I had intended to require that each method
must accept the same number of arguments as the generic function. My
proposal could be read otherwise if you believe that "is an error" means
the programmer can do it anyway, but I hadn't intended to propose that.
I think we all agree that requiring that the minimum number of arguments,
maximum number of arguments, and keyword parameter keywords be consistent
between all methods and the generic function is acceptable, at least I
don't recall anyone arguing against it and several people have proposed it.
So, I see two different schemes for generic function defaulting:
GFD #1. the defaults from the defgeneric are used only for method
lookup. This is the kind I described above.
GFD #2. the defaults from the defgeneric are used for method lookup
and also passed to the method.
Actually, the kind you described above seems to me to be GFD #2.
But that's not important, unless it means that I have completely
misunderstood what you're saying. I think the breakdown into GFD #1
and GFD #2 really clarifies what's going on here.
There is a fundamental conceptual difference here. I am not sure which
I prefer, but I am leaning towards number 1. Because...
My proposal of 2 September was intended to eliminate the distinction
between these by declaring invalid any program that can tell the difference.
I guess that was not very clear in the proposal. Does anyone have reasons
why programs that can tell the difference between GFD #1 and GFD #2 should
be allowed? This would mean that the optional argument would be defaulted
to one value for method selection and then be defaulted to a different value
in the actual method, or else not accepted as an argument at all if we
didn't require the defmethod and defgeneric arguments to be consistent.
If there is no reason to allow programs that can tell the difference between
GFD #1 and GFD #2, then I think we should forbid them, since obviously this
leads to confusion.
Date: Thu, 4 Sep 86 16:15 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
(make-specializable 'print)
This is the same as:
(defgeneric print (object &optional stream))
(defmethod print (x &optional ((stream gee-whiz-display))) ...)
But (let ((*standard-output* <instance of the gee-whiz-display>))
(print <lisp-object>))
calls the wrong method! This is what I have been complaining about all
along. This is the key issue.
I agree that this is the key issue. Using GFD #1, there is no problem.
You would have to specify a default value for the second argument to the
PRINT generic function as a whole:
(defgeneric print (object &optional (stream *standard-output*))
Then the example:
(let ((*standard-output* <instance of the gee-whiz-display>))
(print <lisp-object>))
would get the right method.
-------
This example is obscured by the unclarity of the definition of
PRINT in the Common Lisp manual, which makes it unclear exactly where the
substitution of the value of *standard-output* for an unsupplied second
argument happens. I in fact thought when I sent that message that
(make-specializable 'print) would be the same as (defgeneric print
(object &optional (stream *standard-output*)), but I hadn't read CLtL
carefully enough to realize that PRINT accepts NIL as a stream argument.
Of course we don't really want to specialize PRINT anyway, since it's
the function that outputs a carriage return before the object and a
space after. What we really want to specialize is the internal
function, not named by CLtL, that is called by all of PRINT, PRIN1,
PRINC, PPRINT, WRITE, FORMAT ~S, PRIN1-TO-STRING, etc. But that ruins
the example, since surely that internal function has the stream as
a required argument, not an optional one.
- - -
I think that we are actually in complete agreement here. For an optional
argument to be used for discrimination, the defaulting has to be in the
defgeneric. Now we can decide whether, when you do a defmethod without
first doing a defgeneric, it signals an error or generates an implied
defgeneric according to well-defined rules.
I think we also agree that the arglists of generic functions and methods
must be consistent; we need to define precisely what that means, but
intuitively I think it means that they are equal except for the names of
the arguments and the type qualifications in the methods. Seeing the
confusion that can arise from subtle inconsistencies, e.g. different
default values for optional arguments, I now favor requiring stronger
consistency than mere agreement of number of arguments. This needs to
be refined to a more precise specification; if people agree with the
intuitive specification I will volunteer to produce a precise
specification for consideration.
Does anyone disagree that we agree?
∂15-Sep-86 1436 Masinter.pa@Xerox.COM Re: Defmethod syntax
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Sep 86 14:34:48 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 15 SEP 86 14:20:18 PDT
Date: 15 Sep 86 14:22 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Defmethod syntax
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Mon, 15 Sep 86 13:37 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CommonLoopsCore↑.PA@Xerox.COM
Message-ID: <860915-142018-6089@Xerox>
sorry... I was off the mailing list for a while, and missed the earlier
discussion.
I'm happy with spelling the new way of defining methods some other way
than "defmethod". I don't care what the name is exactly, but I'd like it
to be short & simple to remember; I thought define-method was too long.
(I originally long ago proposed spelling it "defun".)
Here's some more names
defpartial (defines a partial function)
defmeth (shorter than define-method, but otherwise an unfortunate
abbrev)
deffunction (I know this is longer, but it emphasizes the "function"
nature
of the beast well enough that I include it)
deffn even shorter than defun, defines "partial functions" (don't
groan)
I like this one the most. You can make a function into a method
with a single character delete.
∂15-Sep-86 1436 Owners-commonloopscore↑.pa@Xerox.COM Goals of the Specification
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Sep 86 14:34:30 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 15 SEP 86 12:20:39 PDT
Return-Path: <RPG@SAIL.STANFORD.EDU>
Redistributed: commonloopscore↑.pa
Received: from SAIL.STANFORD.EDU (SU-AI.ARPA) by Xerox.COM ; 15 SEP 86
12:20:21 PDT
Date: 15 Sep 86 12:20 PDT
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Subject: Goals of the Specification
To: commonloopscore↑.pa@Xerox.COM
Message-ID: <860915-122039-5943@Xerox>
It is difficult to design for a set of goals set in a meeting
that hardly anyone attened. Masinter did not attend it; neither
did I. You cannot blame us for tryin to use only good design criteria
rather than these hidden goals.
I would say that the goals of backwards compatibility are admirable
as long as they don't imply a poorer design. We will probably have
to live with the new specification longer than the switchover period.
One can claim that Common Lisp itself is a poorer language because
it had to be compatible with MacLisp and like other existing Lisps.
I have few problems with requiring additional Common Lispage as part
of the CommonLos spec.
-rpg-
∂15-Sep-86 1615 Owners-commonloopscore↑.pa@Xerox.COM Goals of the Specification
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Sep 86 16:15:47 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 15 SEP 86 15:58:51 PDT
Return-Path: <Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM>
Redistributed: commonloopscore↑.pa
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM ([192.10.41.41]) by
Xerox.COM ; 15 SEP 86 15:58:13 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 80550;
Mon 15-Sep-86 18:44:05 EDT
Date: Mon, 15 Sep 86 18:44 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Goals of the Specification
To: commonloopscore↑.pa@Xerox.COM
In-Reply-To: <860915-122039-5943@Xerox>
Message-ID: <860915184400.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 15 Sep 86 12:20 PDT
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
It is difficult to design for a set of goals set in a meeting
that hardly anyone attened. Masinter did not attend it; neither
did I. You cannot blame us for tryin to use only good design criteria
rather than these hidden goals.
The goals weren't set in that four-person meeting at MIT on Friday after
the Lisp conference, but in earlier discussion that I thought you were
involved in (but I might be remembering wrong). There was a policy
statement that we decided we weren't ready to hand out during the Lisp
Conference (or the object-oriented programming committee meeting that
coincided with the Lisp conference) which contained the goals. I agree
that I erred in assuming that everyone on this mailing list had already
bought into a particular list of goals (in fact I have no idea who is
the complete population of this mailing list).
In any case, if we don't even agree on the goals of this project, we'd
better bring that out into the open and agree on some goals as soon as
possible. Having heard almost nothing from you, I can only go on what
I have. We Symbolics people are about to net-mail out a proposed
statement of goals, which can serve as a starting point for discussion.
Maybe that will help.
I would say that the goals of backwards compatibility are admirable
as long as they don't imply a poorer design. We will probably have
to live with the new specification longer than the switchover period.
One can claim that Common Lisp itself is a poorer language because
it had to be compatible with MacLisp and like other existing Lisps.
One has.
I have few problems with requiring additional Common Lispage as part
of the CommonLos spec.
Again this is a question of goals. Is it more important to make it easy
for every Common Lisp implementation to implement this spec, or to make
the spec include all the good ideas we might have thought of? The only
statement of goals for this project I have ever seen speaks of simplicity
and implementability.
∂15-Sep-86 1743 Masinter.pa@Xerox.COM Re: Goals of the Specification
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Sep 86 17:43:34 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 15 SEP 86 16:17:58 PDT
Date: 15 Sep 86 16:15 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Goals of the Specification
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Mon, 15 Sep 86 18:44 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: commonloopscore↑.pa@Xerox.COM
Message-ID: <860915-161758-6228@Xerox>
The current list contents of commonloopscore↑.pa@xerox.com is:
Bobrow.pa Common-Lisp-Class-archive@Stony-Brook.SCRC.Symbolics.COM
COMMON-LISP-OBJECT-SYSTEM@SU-AI.ARPA
CommonLoops-Spec-Archive@AI.AI.MIT.EDU DLW@QUABBIN.SCRC.Symbolics.COM
edsel!lgd@navajo.stanford.edu Gregor.pa Kahn.pa Lanning.pa
LGD@SU-AI.arpa Masinter.pa Moon@STONY-BROOK.SCRC.Symbolics.COM
SKeene@STONY-BROOK.SCRC.Symbolics.COM
I assume RPG gets the mail via COMMON-LISP-OBJECT-SYSTEM@SU-AI.ARPA,
although I don't know who else does. I'm not sure who LDG is (I assume
someone at Lucid) or SKeene@STONY-BROOK.SCRC.Symbolics.COM.
I don't think I object to what I've heard of the goals, I just didn't
see the list. Avoiding obvious name conflicts with Flavors and allowing
mechanical translation of Flavors, while a bow to backward
compatibility, is not an onerous one.
∂15-Sep-86 2005 Owners-CommonLoopsCore↑.PA@Xerox.COM Defmethod syntax
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Sep 86 20:04:12 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 15 SEP 86 19:22:39 PDT
Return-Path: <Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.PA
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM ([192.10.41.41]) by
Xerox.COM ; 15 SEP 86 19:22:24 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 80612;
Mon 15-Sep-86 22:20:24 EDT
Date: Mon, 15 Sep 86 22:20 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Defmethod syntax
To: CommonLoopsCore↑.PA@Xerox.COM
In-Reply-To: <860913002227.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <860915222018.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
I prefer (1b), with (1a) a close second. (2) has too many funny
restrictions and (3) has too many special form names.
∂15-Sep-86 2101 Owners-CommonLoopsCore↑.pa@Xerox.COM default optional arguments to a generic function
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Sep 86 21:01:37 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 15 SEP 86 20:59:04 PDT
Return-Path: <Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.pa@XEROX.ARPA
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM ([192.10.41.41]) by
Xerox.COM ; 15 SEP 86 20:58:46 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 80635;
Mon 15-Sep-86 23:57:49 EDT
Date: Mon, 15 Sep 86 23:57 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: default optional arguments to a generic function
To: CommonLoopsCore↑.pa@Xerox.COM
In-Reply-To: <860915152433.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <860915235743.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: Mon, 15 Sep 86 15:24 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
I have a bit more to say on this topic. I'll try to keep it short.
Date: Sun, 14 Sep 86 18:04 PDT
From: Gregor.pa@Xerox.COM
...So, I see two different schemes for generic function defaulting:
GFD #1. the defaults from the defgeneric are used only for method
lookup. This is the kind I described above.
GFD #2. the defaults from the defgeneric are used for method lookup
and also passed to the method.
There is a fundamental conceptual difference here. I am not sure which
I prefer, but I am leaning towards number 1.
A good reason to prefer GFD #1 is that it doesn't interfere with
supplied-p parameters in the methods. This is particularly important
for people who want to program with defmethod instead of defun, and
hence require that defmethod supports all the features of defun. Ken
Kahn's suggestion of an alternate method-defining macro that does both
the defgeneric and the defmethod could take care of this, but it would
be nice to avoid introducing that extra special form if it isn't really
necessary.
A bad reason to prefer GFD #2 is that it is easier to implement the
discriminating function in straight Common Lisp, because methods are
always called with the same number of arguments.
If there is no reason to allow programs that can tell the difference
between GFD #1 and GFD #2, then I think we should forbid them, since
obviously this leads to confusion.
Because of supplied-p parameters, I have to back off on this. I think
we should go with GFD #1, same as Gregor leans toward.
I think we also agree that the arglists of generic functions and methods
must be consistent....
I have an anecdote that might illuminate the issue of whether two
methods for the same generic function should be allowed to have
different default-value forms for an optional argument, even when the
argument is not used for discrimination. We have a stream operation
called read-cursorpos. It takes an optional argument which is the units
in which the position is to be measured (pixels or characters). The
default value for that argument is supposed to be pixels, but one or two
of the methods defaulted it to characters instead. This caused bugs,
especially when streams are nested and one stream applies read-cursorpos
to another stream. Because Flavors only requires that methods have
consistent numbers of arguments, and doesn't check consistency of
default-value forms, these bugs had to be found the hard way. I tried
to think of an example where the freedom to have different default values
for an optional argument in different methods would be useful, but
could not come up with one.
Here is a proposed precise definition for arglist consistency. It's a
bit longwinded, but I found that was necessary to make it precise and
cover all the cases. Comments and amendments are invited. Terminology
follows CLtL p.60.
The lambda-lists of all methods for a given generic function must be
consistent with each other and with the lambda-list in the defgeneric
[if defgeneric is optional, add "if present"]. Attempting to define a
method with an inconsistent lambda-list signals an error; a program
development environment might offer to modify the conflicting
lambda-lists to make them all consistent.
To compare two lambda-lists for consistency, use the following rules:
(1) The numbers of required parameters must be equal.
(2) The numbers of optional parameters must be equal. In addition, the
initforms for corresponding optional parameters must be equal (using the
Lisp function EQUAL); an omitted initform is the same as NIL.
(3) If one lambda-list contains &rest or &key, so must the other
lambda-list. It is valid for one lambda-list to have &rest and the
other to have &key.
(4) If both lambda-lists contain &key, the sets of keywords must be the
same, except that it is valid for a keyword to appear only in one
lambda-list if the other lambda-list contains &allow-other-keys.
(5) Keyword parameters with equal keywords that appear in both
lambda-lists must have equal initforms (using the Lisp function EQUAL);
an omitted initform is the same as NIL.
(6) Keyword parameters of a method, whose keywords are not among the
generic function's keyword parameters' keywords, cannot be type
qualified (i.e. cannot be used for discrimination).
(7) If an initform that appears in both lambda-lists references an
earlier parameter, that parameter must have the same name in both
lambda-lists and in the case of keyword parameters the parameter
specifiers must appear in the same order. This ensures that variable
names in initforms have the same meaning everywhere the initform
appears. [If defmethod is allowed inside a non-top-level lexical
context, add appropriate additional language about captured free
variables.]
(8) Ignore &aux and everything after it.
Note that parameter names, type qualifiers, and the names and presence
of supplied-p parameters have no effect on lambda-list consistency.
Lambda-list consistency in more abstract terms is: the minimum number of
arguments must be equal; the maximum number of arguments must be equal;
default values for optional and keyword parameters must be consistent;
the set of keyword parameter keywords must be consistent; the defgeneric
must contain all argument-defaulting information required for
discrimination.
These rules are stricter than necessary in the sense that initforms are
compared with EQUAL, rather than a predicate that determines whether the
result of evaluating them would be EQUAL. Thus "foo" and (quote "foo")
would not be considered consistent initforms. Furthermore, if an
initform references a parameter earlier in the lambda-list, the name of
the parameter matters. I don't think the stricter rules hurt anything,
and they are simpler to explain than the minimal rules would be.
∂16-Sep-86 0626 Owners-CommonLoopsCore↑.PA@Xerox.COM Proposed Goals (Statement for OOPSLA)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 16 Sep 86 06:26:24 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 16 SEP 86 06:24:50 PDT
Return-Path: <skeene@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.PA
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
Xerox.COM ; 16 SEP 86 06:24:34 PDT
Received: from JUNCO.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 104483; Tue
16-Sep-86 09:16:58 EDT
Date: Tue, 16 Sep 86 09:16 EDT
From: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Proposed Goals (Statement for OOPSLA)
To: CommonLoopsCore↑.PA@Xerox.COM
Message-ID: <860916091654.1.SKEENE@JUNCO.SCRC.Symbolics.COM>
I think it's important for us to start thinking about OOPSLA in regards to
this standardization effort. It would be best to pass out something
written, because that way we can all agree before-hand on the written
statement, and after the meeting there won't be any confusion about what
was said.
I've put together a draft statement that could either stand alone, or be
the preface to some more specific documentation (if we have that in time).
Please let me know what you think about this Statement, and also your
thoughts on any other documentation that we could prepare (and get
consensus on) in time for the conference.
--------------------------------------------------------------
TOWARD A COMMON LISP STANDARD FOR OBJECT-ORIENTED PROGRAMMING
This brief paper summarizes the work that is now going on toward defining a
new Common Lisp standard for object-oriented programming.
HISTORY AND MOTIVATION
Many people in the Common Lisp community see a need for defining a standard
for object-oriented programming that would be part of Common Lisp. The
primary benefit of such a standard would be the ability to write portable
Common Lisp code in an object-oriented style.
At the Common Lisp committee meeting in Boston in December 1985, many
vendors of application software made it clear how important such a standard
is to them. Again at the ACM Lisp Conference in Cambridge in August 1986,
the same point was made.
After the ACM Lisp Conference, there was a meeting of the Common Lisp
Object-oriented Programming Committee. A clear consensus was reached that
we should begin work immediately to define a standard. Representatives
from Xerox, Lucid, Symbolics, LMI, HP, Sun, and the Japanese CommonLisp
committee supported this consensus.
A working group composed of representatives from Xerox and Symbolics met
after the ACM Lisp Conference. At that meeting we reached agreement on
several general goals.
In brief, the standard will be based on the meta-object framework of
CommonLoops, which allows experimentation with different philosophies of
object-oriented programming. The standard will also take advantage of the
years of experience of Flavors, and include Flavors features such as
declarative method combination. The standard will not be CommonLoops, nor
will it be Flavors; however it will incorporate the most useful features
from both.
PROGRESS IN AUGUST AND SEPTEMBER
During August and September, representatives from Xerox, Symbolics, and
Lucid began work on a draft specification of the standard. We started with
the basic programmer interface for defining new classes and writing methods
and generic functions. This work is ongoing, but it has not yet reached a
state where documentation is available. [We hope that this sentence turns
out to be false, but for the moment it is true.]
GOALS FOR THE STANDARD
Some high-level goals were stated and agreed-upon:
Sound basis The standard will include the aspects of object-oriented
programming that are well-understood at this time. The
standard will omit ideas that are still subjects for
research.
Flexibility The meta-object protocol of the standard will offer a
flexible framework for other designers to implement
different schemes. This encourages exploration of
different styles of object-oriented programming.
Power The standard will offer the basic tools for writing
programs in an object-oriented style, and will be powerful
enough that it meets the needs of most programs. It should
not be necessary for programmers to extend the system to do
straightforward object-oriented programming.
Simplicity The standard will specify just the language, not the
programming tools and interactive development environment.
Compatibility It should be a convenient and simple procedure to translate
programs written in CommonLoops or Flavors to the new
standard. We intend to provide tools that will perform the
translation automatically.
Implementation The standard will allow efficient implementation on stock
hardware as well as specialized machines.
FEATURES TO BE INCLUDED IN THE STANDARD
We are planning on including the following features. This is not an
exhaustive list, but is intended to communicate some of the areas of
agreement that have been reached.
Generic functions
The standard will use the normal Lisp function-calling
syntax.
Class and Type Space Merging
Every object in the Lisp system has a class and hence can
be used to select methods.
Dispatching The standard will allow for several types of dispatching,
including classical methods (which dispatch on a single
object) and multi-methods (which dispatch on more than one
object).
Multiple inheritance
Modules of behavior can be combined together freely; they
need not fit into a rigid hierarchy.
Meta-objects The standard defines objects for the major implementation
entities of the system to allow for extensibility.
Classes, methods, and generic functions all have
corresponding objects, organized by well-defined,
documented protocols.
Declarative Method Combination
Method selection and combination are controlled
declaratively, making it easier to construct programs from
a collection of modules. Users can easily define new
method combination paradigms.
FUTURE PLANS
The working group intends to develop a draft specification for the
standard. We will continue to involve the community in the feedback
process.
We will produce a portable implementation by evolving Portable Common Loops
to track the new specification. The portable implementation will enable
the community to experiment with the ideas, gain a deeper understanding of
the ideas than is possible with only a specification, and ensure that the
new object-oriented programming language receives adequate real-life
testing before its adoption as a standard.
/sub
gregor.pa@xerox,bobrow.pa@xerox
My Version of Sonya's Blurb
I spent 10 minutes revising Sonya's note - hers turned out to be
fairly good. I've laid the groundwork to call the thing CommonLoops,
but I've spiced the description with some amount of flavor.
-rpg-
ps. Oh yeah, here it is:
TOWARD A COMMON LISP STANDARD FOR OBJECT-ORIENTED PROGRAMMING
This brief paper summarizes the work that is now going on toward defining a
new Common Lisp standard for object-oriented programming.
HISTORY AND MOTIVATION
There is currently substantial experience with object-oriented
programming paradigms within a variety of contexts. The two groups
have have the most experience in this area are Symbolics and Xerox.
Flavors, an important object-oriented programming extension to Lisp,
has been in use for more than 5 years. Over that period many valuable lessons
have been learned about object-oriented programming in Lisp. In 1985,
Symbolics took these lessons to heart and designed New Flavors, which
is a compatible extension to Flavors.
Xerox has had more than 10 years of experience with object-oriented
programming, both within the Lisp tradition and within the Smalltalk
tradition. Over that period many lessons were learned, and in 1985 Xerox
began to design a new object-oriented programming extension to Common
Lisp, called CommonLoops.
In mid-1985 these two groups became aware of each other, and a significant
cross-fertilization occurred: CommonLoops absorbed some of the ideas
in New Flavors that weren't already in CommonLoops. The remarkable point,
though, was how similar these two object-oriented extensions to Lisp were.
Many people in the Common Lisp community now see a need for defining a
standard for object-oriented programming that would be part of Common
Lisp. The primary benefit of such a standard would be the ability to
write portable Common Lisp code in an object-oriented style.
At the Common Lisp committee meeting in Boston in December 1985, many
vendors of application software made it clear how important such a
standard is to them. Again at the ACM Conference on Lisp and Functional
Programming in Cambridge in August 1986, the same point was made.
After the ACM Conference there was a meeting of the Common Lisp
Object-oriented Programming Committee. A clear consensus was reached that
work should begin immediately to define a standard. Representatives
from Xerox, Lucid, Symbolics, LMI, HP, Sun, and the Japanese CommonLisp
committee supported this consensus.
A working group composed of representatives from Xerox and Symbolics met
after the ACM Conference; at the meeting this working group reached
agreement on several general goals.
In brief, the standard will be based on the meta-object framework of
CommonLoops, which allows experimentation with different philosophies of
object-oriented programming. Additional features from New Flavors will be
added to CommonLoops to flesh out the programmer interface; in particular,
a declarative method combination facility and a classical method
definition syntax patterned after those features in New Flavors will be
added to CommonLoops to create an extension to Common Lisp that represents
the best features of both systems seamlessly merged.
PROGRESS IN AUGUST AND SEPTEMBER
During August and September, representatives from Xerox, Symbolics, and
Lucid began work on a draft specification of the standard. This working
group started with the basic programmer interface for defining new classes
and writing methods and generic functions. This work is ongoing, but a
draft of the programmer interface is available - the meta-object protocol
specification will be available soon.
GOALS FOR THE STANDARD
Some high-level goals were stated and agreed-upon:
Sound basis The standard will include the aspects of object-oriented
programming that are well-understood at this time. The
standard will omit ideas that are still subjects for
research.
Flexibility The meta-object protocol of the standard will offer a
flexible framework for other designers to implement
different schemes. This encourages exploration of
different styles of object-oriented programming.
Power The standard will offer the basic tools for writing
programs in an object-oriented style, and will be powerful
enough that it meets the needs of most programs. It should
not be necessary for programmers to extend the system to do
straightforward object-oriented programming.
Simplicity The standard will specify just the language, not the
programming tools and interactive development environment.
Compatibility It should be a convenient and simple procedure to translate
programs written in CommonLoops or New Flavors to the new
standard. We intend to provide tools that will perform the
translation automatically.
Implementation The standard will allow efficient implementation on stock
hardware as well as specialized machines.
FEATURES TO BE INCLUDED IN THE STANDARD
The following features wil be included in the standard.. This is not an
exhaustive list, but is intended to communicate some of the areas of
agreement that have been reached.
Generic functions
The standard will use the normal Lisp function-calling
syntax.
Class and Type Space Merging
Every object in the Lisp system has a class and hence can
be used to select methods.
Dispatching The standard will allow for several types of dispatching,
including classical methods (which dispatch on a single
object) and multi-methods (which dispatch on more than one
object).
Multiple inheritance
Modules of behavior can be combined together freely; they
need not fit into a rigid hierarchy.
Meta-objects The standard defines objects for the major implementation
entities of the system to allow for extensibility.
Classes, methods, and generic functions all have
corresponding objects, organized by well-defined,
documented protocols.
Declarative Method Combination
Method selection and combination are controlled
declaratively, making it easier to construct programs from
a collection of modules. Users can easily define new
method combination paradigms.
FUTURE PLANS
The working group intends to develop a draft specification for the
standard. The specification process will involve the community in the
feedback process.
There will be a portable implementation based on Portable Common Loops,
which will evolve to to track the new specification. The portable
implementation will enable the community to experiment with the ideas,
gain a deeper understanding of the ideas than is possible with only a
specification, and ensure that the new object-oriented programming
language receives adequate real-life testing before its adoption as a
standard.
∂16-Sep-86 0630 Owners-commonloopscore↑.pa@Xerox.COM Re: Goals of the Specification
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 16 Sep 86 06:30:52 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 16 SEP 86 06:29:26 PDT
Return-Path: <skeene@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: commonloopscore↑.pa
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
Xerox.COM ; 16 SEP 86 06:28:46 PDT
Received: from JUNCO.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 104492; Tue
16-Sep-86 09:25:51 EDT
Date: Tue, 16 Sep 86 09:25 EDT
From: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Goals of the Specification
To: Masinter.pa@Xerox.COM
cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, commonloopscore↑.pa@Xerox.COM
In-Reply-To: <860915-161758-6228@Xerox>
Message-ID: <860916092549.2.SKEENE@JUNCO.SCRC.Symbolics.COM>
Date: 15 Sep 86 16:15 PDT
From: Masinter.pa@Xerox.COM
The current list contents of commonloopscore↑.pa@xerox.com is:
Bobrow.pa Common-Lisp-Class-archive@Stony-Brook.SCRC.Symbolics.COM
COMMON-LISP-OBJECT-SYSTEM@SU-AI.ARPA
CommonLoops-Spec-Archive@AI.AI.MIT.EDU DLW@QUABBIN.SCRC.Symbolics.COM
edsel!lgd@navajo.stanford.edu Gregor.pa Kahn.pa Lanning.pa
LGD@SU-AI.arpa Masinter.pa Moon@STONY-BROOK.SCRC.Symbolics.COM
SKeene@STONY-BROOK.SCRC.Symbolics.COM
I assume RPG gets the mail via COMMON-LISP-OBJECT-SYSTEM@SU-AI.ARPA,
although I don't know who else does. I'm not sure who LDG is (I assume
someone at Lucid) or SKeene@STONY-BROOK.SCRC.Symbolics.COM.
I'm a writer at Symbolics. -- Sonya Keene
I don't think I object to what I've heard of the goals, I just didn't
see the list. Avoiding obvious name conflicts with Flavors and allowing
mechanical translation of Flavors, while a bow to backward
compatibility, is not an onerous one.
∂16-Sep-86 1128 Owners-CommonLoopsCore↑.pa@Xerox.COM Re: default optional arguments to a generic function
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 16 Sep 86 11:28:28 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 16 SEP 86 10:39:58 PDT
Redistributed: CommonLoopsCore↑.pa
Received: from Cabernet.ms by ArpaGateway.ms ; 16 SEP 86 10:38:19 PDT
Date: 16 Sep 86 10:37 PDT
From: Bobrow.pa@Xerox.COM
Subject: Re: default optional arguments to a generic function
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Mon, 15 Sep 86 23:57 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CommonLoopsCore↑.pa@Xerox.COM
Message-ID: <860916-103958-6836@Xerox>
GFD #1. the defaults from the defgeneric are used only for method
lookup. This is the kind I described above.
GFD #2. the defaults from the defgeneric are used for method lookup
and also passed to the method.
There is a fundamental conceptual difference. I think the notion of
supplying defaults is part of the contract between the generic function
and the world. This is an argument for GFD #1. We all seem to agree
that defmethods, if they specify optionals, must agree with the generic
function. If the EQUALS rule is used for defaults (I support this),
then I see no reason for the default forms to be evaluated twice. If
methods can have exactly the same supplied-p args as specified in the
generic function (no more, no less - just local renaming allowed) then
there is no penalty for passing supplied-p args to each method as
"required args". The calling sequence is uniform.
Given:
(defgeneric foo (x &optional y (z *v1* supplied-z)) ...)
then the following is legal
(defmethod foo ((x c1) &optional ((y c2)) (z *v1* my-supplied-z))) ..)
and the following are illegal
(defmethod foo ((x c1) &optional (y NIL supplied-y)(z *v1*
my-supplied-z))) ..)
(defmethod foo ((x c1) &optional y (z *v1* ))) ..)
One issue to be addressed is the following. If we insist on the EQUALS
rule, then if the default value form changes in the defgeneric, it must
be changed in all methods. This redundancy is bad design. To allow
arg-specification and supplied-p specification, I suggest another
keyword &optional-spec. Following &optional-spec can be
{varName|(varName arg-specifier [supplied-p-var])}*
where the interpretation is the obvious one, given in my message of last
week. The rule of supplied-p correspondence still holds, but no default
value form need be specified.
-- danny
∂16-Sep-86 1413 Gregor.pa@Xerox.COM the kinds of method lookup people claim they want
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 16 Sep 86 14:12:58 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 16 SEP 86 14:00:48 PDT
Date: Tue, 16 Sep 86 13:59 PDT
From: Gregor.pa@Xerox.COM
Subject: the kinds of method lookup people claim they want
To: CommonLoopsCore↑.pa@Xerox.COM
Message-ID: <860916135909.5.GREGOR@AVALON.XEROX-PARC>
Line-fold: no
I spent lunch today listening to people talk about the kinds of method
lookup which they would like to have CommonLoops support. I was struck
by the variety of things which people claimed would be natural or
convenient or even essential. By the end of lunch I was very confused
about what we should do about discriminating on optional arguments.
In the interest of confusing the rest of you, I thought I would collect a
list of all the cases of method definition people thought they would
want. Please add any other examples or potential screw cases.
NOTE: In each of these examples I have used some syntax and some
defining forms which I intend only to express the example. Do not
regard the syntax I have used as a proposal for how we should do
anything.
Case 1a. "draw-line"
draw-line takes an optional, the width of the line in device dependent
units. Because they are device dependent units, each individual method
would like to default this argument on its own.
(defmethod draw-line ((dev printer) p1 p2 &optional (width 7))
...)
(defmethod draw-line ((dev window) p1 p2 &optional (width 1))
...)
Case 1b.
Within case 1, some methods may want to take an extra argument. Also
see case 3 which is similar.
(defmethod draw-line ((d gray-display) p1 p2
&optional (width 3)
(gray *gray1*))
..)
Case 2. "draw (GFD#2)"
The generic function takes an optional argument. For all the methods,
the optional argument should default to the same value. In addition,
method lookup should be based on the value of the optional argument
(after defaulting) and the defaulted value should be passed in. This
corresponds to what I previously called GFD#2.
(defgeneric draw (thing &optional (place *draw-window*))
"Draw thing on place.")
(defmethod draw ((thing line) (place raster-display)) ...)
(defmethod draw ((thing line) (place vector-display)) ...)
People have also said that within the individual methods they would like
to have access to the supplied-p information for the optional argument.
Case 3. "move"
A generic function (e.g. move) has only classical methods. Some of the
methods want to accept more arguments than others. For example: move
when then first argument is a block takes a position to move to, but
move when the first argument is a rabbit takes no extra arguments (the
rabbit will jump up and down).
(defmethod move ((b block) to-x to-y) ..)
(defmethod move ((r rabbit)) ..)
Case 4. "Guy's proposal"
In this porposal, method lookup checks argument specifiers for only the
supplied arguments. When there are two arguments supplied, the most
specific of the two argument methods is called.
(defmethod foo (a b &optional (c x) (d y)) body)
is simply an abbreviation for
(defmethod foo (a b) (let ((c x) (d y)) body))
(defmethod foo (a b c) (let ((d y)) body))
(defmethod foo (a b c d) body)
So that:
(defmethod gls ((a boat) &optional ((p plane) *default*)) ..)
(defmethod gls ((a speed-boat)) ...)
(foo <a speed-boat>) ;runs method 2
(foo <a speed-boat> <a plane>) ;runs method 1
-------
∂16-Sep-86 1841 Owners-CommonLoopsCore↑.pa@Xerox.COM run-super
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 16 Sep 86 18:41:07 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 16 SEP 86 16:24:56 PDT
Return-Path: <Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.pa
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM ([192.10.41.41]) by
Xerox.COM ; 16 SEP 86 16:23:57 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 81031;
Tue 16-Sep-86 17:10:40 EDT
Date: Tue, 16 Sep 86 17:10 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: run-super
To: CommonLoopsCore↑.pa@Xerox.COM
References: <860905004612.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <860916171027.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
The referenced message, from 5 September, contains two implementations
of RUN-SUPER in Flavors. This message contains a third implementation
that eliminates some problems with the other two implementations, which
were discussed in that message. All three of these implementations have
been tested and work. To simply things, I removed :AROUND methods from
this version, but it would only take a few lines of code to put them
back in if we wished to do so.
I see no reason why this couldn't be the default method-combination type
in Common Lisp Classes. Compilation will be a little slower than in
Flavors, but not much slower, and code that doesn't use run-super will
not pay any efficiency cost, while code that does use run-super will be
quite efficient.
Of course this exact implementation could not be used, because it uses
Flavors interfaces in place of meta-object protocols, uses Symbolics'
code-walker rather than one that can be assumed to be present in every
implementation, and contains machine-dependencies, especially connected
with the way method dispatching works in our system. That's not
important, the important thing is the semantics of how RUN-SUPER and
method-combination fit together, which is:
all the :BEFORE methods are executed, most-specific first
the most specific primary method is executed, and supplies the
value(s)
if it uses RUN-SUPER, that calls the next primary method, and so on
if RUN-SUPER exhausts the supply of primary methods, it signals an
error
all the :AFTER methods are executed, least-specific first
Shall we make this the default method-combination type, or does anyone
object? (Myself, I object to the name RUN-SUPER, and maybe we can think
of a more expressive name. If not, I can live with that one.)
Most of the hair in this code is connected with optimizations so that if
run-super is not used, the compiled code is exactly the same as in
Flavors
:daemon method-combination (no extra overhead for run-super).
;;;; Dynamically plus lexically scoped version, avoids problems of both
the above.
;;;; This scheme uses more machine-dependencies to avoid an extra level
of
;;;; lambda in the continuations.
;;;; I removed :AROUND methods but they could easily be added back in.
;;; List of alternating methods and self-mapping-tables, used by
RUN-SUPER
(DEFVAR *SUPERCLASS-CONTINUATIONS*)
;;; Shadowed by a MACROLET
(DEFUN RUN-SUPER ()
(ERROR "RUN-SUPER not called from a proper lexical environment.
RUN-SUPER is only valid in a primary method with :SUPER-DAEMON
method-combination."))
;;; Appears at the tail of *SUPERCLASS-CONTINUATIONS*
;;; Change this to a function that just returns NIL if you prefer that
semantics
(DEFUN RUN-SUPER-EXHAUSTED (&REST IGNORE)
(ERROR "RUN-SUPER called from the least specific method; no more
methods are available."))
(DEFINE-METHOD-COMBINATION :SUPER-DAEMON ()
((BEFORE "before" :EVERY :MOST-SPECIFIC-FIRST (:BEFORE))
(PRIMARY "primary" :EVERY :MOST-SPECIFIC-FIRST () :DEFAULT)
(AFTER "after" :EVERY :MOST-SPECIFIC-LAST (:AFTER)))
(:METHOD-TRANSFORMER
;; Deal with run-super by transforming the method's arglist and
body
(:METHOD-ARGLIST
(MULTIPLE-VALUE-SETQ (METHOD-ARGLIST METHOD-BODY)
(TRANSFORM-SUPER-DAEMON-METHOD FUNCTION-SPEC METHOD-ARGLIST
METHOD-BODY)))
(:METHOD-BODY METHOD-BODY))
;; Remove from dependencies the primary methods that cannot be reached
by RUN-SUPER
(SETQ PRIMARY (LOOP FOR METHOD IN PRIMARY
COLLECT METHOD
WHILE (METHOD-USES-RUN-SUPER METHOD)))
;; Return appropriate method combining form
`(MULTIPLE-VALUE-PROG2
,(CALL-COMPONENT-METHODS BEFORE)
,(COND ((NULL PRIMARY) `NIL)
((AND (NULL (REST PRIMARY))
(NOT (METHOD-USES-RUN-SUPER (FIRST PRIMARY))))
(CALL-COMPONENT-METHOD (FIRST PRIMARY))) ;Optimize single-method
case
(T
;; Stash the machine-dependent information needed for run-super,
;; then call the first primary method, which will call the rest of
them.
`(STACK-LET ((*SUPERCLASS-CONTINUATIONS*
(LIST ,@(LOOP FOR METHOD IN (REST PRIMARY)
COLLECT `(FUNCTION ,METHOD)
COLLECT `(GET-FLAVOR-MAPPING-TABLE-FOR-INSTANCE
SELF ',(METHOD-FLAVOR METHOD)))
#'RUN-SUPER-EXHAUSTED)))
,(CALL-COMPONENT-METHOD (FIRST PRIMARY)))))
,(CALL-COMPONENT-METHODS AFTER)))
;;; Determine whether this method needs a binding of
*SUPERCLASS-CONTINUATIONS*
;;; This works by calling a machine-dependent facility
(DEFUN METHOD-USES-RUN-SUPER (FUNCTION-SPEC)
(MULTIPLE-VALUE-BIND (VALUE FOUND)
(COMPILER:FILE-DECLARATION FUNCTION-SPEC 'USES-RUN-SUPER)
(IF FOUND VALUE (SI:FUNCTION-SPEC-GET FUNCTION-SPEC
'USES-RUN-SUPER))))
;;; Arrange for NOTE-WHETHER-METHOD-USES-RUN-SUPER to be called when
this method
;;; is defined, via the USES-RUN-SUPER declaration. It would be better
to do this
;;; with meta-object protocols, when we have them.
(PUSHNEW '(USES-RUN-SUPER ADD-NOTE-WHETHER-METHOD-USES-RUN-SUPER)
*DEFMETHOD-DECLARATIONS* :TEST #'EQUAL)
(DEFUN ADD-NOTE-WHETHER-METHOD-USES-RUN-SUPER (FUNCTION-SPEC DECLARATION
IGNORE)
`((NOTE-WHETHER-METHOD-USES-RUN-SUPER ',FUNCTION-SPEC ',(SECOND
DECLARATION))))
;;; Called when a primary method with :SUPER-DAEMON method combination
is defined
(DEFUN NOTE-WHETHER-METHOD-USES-RUN-SUPER (FUNCTION-SPEC USES-RUN-SUPER)
(LET ((CHANGED (AND (FDEFINEDP FUNCTION-SPEC)
(NOT (EQ (SI:FUNCTION-SPEC-GET FUNCTION-SPEC 'USES-RUN-SUPER)
USES-RUN-SUPER)))))
;; Record the information where METHOD-USES-RUN-SUPER can find it.
(IF USES-RUN-SUPER
(SI:FUNCTION-SPEC-PUTPROP FUNCTION-SPEC T 'USES-RUN-SUPER)
(SI:FUNCTION-SPEC-REMPROP FUNCTION-SPEC 'USES-RUN-SUPER))
;; If combined methods have to call a different set of primary
methods now, update them.
(WHEN CHANGED
(RECOMPILE-FLAVOR (METHOD-FLAVOR FUNCTION-SPEC)
:GENERIC (METHOD-GENERIC FUNCTION-SPEC)
:IGNORE-EXISTING-METHODS T))))
;;; Expand any RUN-SUPER in the body of this method into the appropriate
code
;;; to call the next method on the continuation list and rebind that
list to its tail.
;;; This works by calling some machine-dependent facilities.
(DEFUN TRANSFORM-SUPER-DAEMON-METHOD (FUNCTION-SPEC METHOD-ARGLIST
METHOD-BODY)
(DECLARE (VALUES METHOD-ARGLIST METHOD-BODY))
;; This is for primary methods only
(UNLESS (OR (NULL (METHOD-OPTIONS FUNCTION-SPEC))
(EQUAL (METHOD-OPTIONS FUNCTION-SPEC) '(:DEFAULT)))
(RETURN-FROM TRANSFORM-SUPER-DAEMON-METHOD (VALUES METHOD-ARGLIST
METHOD-BODY)))
;; Check whether the method actually uses RUN-SUPER
(MULTIPLE-VALUE-BIND (DECLARATIONS BODY)
(SI:FIND-BODY-DECLARATIONS METHOD-BODY NIL)
(COND ((LT:MAPFORMS (LAMBDA (SUBFORM KIND USAGE RUN-SUPER-USED)
(IGNORE USAGE)
(COND (RUN-SUPER-USED
(VALUES T T)) ;No need to look any further
((AND (LISTP KIND) (EQUAL SUBFORM '(RUN-SUPER)))
(VALUES T T)) ;RUN-SUPER called as a function
(T (VALUES NIL NIL)))) ;else keep looking
(CONS 'PROGN BODY))
;; This method contains a call to RUN-SUPER.
;; Record that for the benefit of METHOD-USES-RUN-SUPER.
(WHEN COMPILER:UNDO-DECLARATIONS-FLAG
(COMPILER:FILE-DECLARE FUNCTION-SPEC 'USES-RUN-SUPER T))
;; Adjust the arglist so we can pass the arguments on to the next
method.
(MULTIPLE-VALUE-BIND (ARGUMENTS APPLY NEW-METHOD-ARGLIST)
(LT:LAMBDA-LIST-ARGUMENTS METHOD-ARGLIST)
(VALUES
NEW-METHOD-ARGLIST
;; Make the body copy the continuations from the special
variable
;; into a lexical variable so that it gets scoped properly if
this method
;; contains RUN-SUPER inside a LAMBDA, and so that if RUN-SUPER
is done
;; twice the same method gets called each time, and put a
MACROLET
;; of RUN-SUPER around the body.
`(,@DECLARATIONS
(DECLARE (USES-RUN-SUPER T))
(LET ((.SUPERCLASS-CONTINUATIONS. *SUPERCLASS-CONTINUATIONS*))
(MACROLET
((RUN-SUPER ()
`(LET ((*SUPERCLASS-CONTINUATIONS* .SUPERCLASS-CONTINUATIONS.))
;; Machine-dependent call similar to CALL-COMPONENT-METHOD
(,',(IF APPLY 'APPLY 'FUNCALL)
(POP *SUPERCLASS-CONTINUATIONS*) ;Method
SELF
(POP *SUPERCLASS-CONTINUATIONS*) ;Mapping-table
.GENERIC.
,',@ARGUMENTS))))
,@BODY))))))
(T
;; Ordinary method that doesn't use RUN-SUPER. Record that fact for
;; the benefit of METHOD-USES-RUN-SUPER, and return original arglist
and body
;; with a declaration added saying it doesn't use run-super.
(WHEN COMPILER:UNDO-DECLARATIONS-FLAG
(COMPILER:FILE-DECLARE FUNCTION-SPEC 'USES-RUN-SUPER NIL))
(VALUES METHOD-ARGLIST
`(,@DECLARATIONS
(DECLARE (USES-RUN-SUPER NIL))
,@BODY))))))
(DEFGENERIC SDTEST (X Y)
(:METHOD-COMBINATION :SUPER-DAEMON))
(DEFFLAVOR SDTEST1 () ())
(DEFFLAVOR SDTEST2 () (SDTEST1))
(DEFFLAVOR SDTEST3 () (SDTEST2))
(DEFMETHOD (SDTEST SDTEST1) (X)
(LIST 1 X))
(DEFMETHOD (SDTEST SDTEST2) (X)
(CONS 2 (RUN-SUPER)))
(DEFMETHOD (SDTEST SDTEST3) (X)
(CONS 3 (RUN-SUPER)))
(SDTEST (MAKE-INSTANCE 'SDTEST3) 105)
; => (3 2 1 105)
∂16-Sep-86 1841 Owners-CommonLoopsCore↑.PA@Xerox.COM What we should agree on before OOPSLA
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 16 Sep 86 18:41:19 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 16 SEP 86 17:51:41 PDT
Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.PA
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
Xerox.COM ; 16 SEP 86 17:51:14 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 105361; Tue
16-Sep-86 20:48:21 EDT
Date: Tue, 16 Sep 86 20:50 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: What we should agree on before OOPSLA
To: CommonLoopsCore↑.PA@Xerox.COM
Message-ID: <860916205006.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Here is what I would like us to try to agree on, in time to write it up
and distribute it to whoever is interested at OOPSLA. I have pared this
list down to what I think is possible if we focus on this. I think it's
important to come up with something real, if we take seriously the
promise we made to the community in August.
- A statement of the goals and general character of this project. This
could be based on what SKeene mailed out this morning (Tuesday), with
modifications resulting from other people's review of it.
- The syntax of the most basic language facilities, with very brief
discussions of their semantics and a statement that additional
facilities are still being discussed. See proposed list below.
- A statement that meta-object protocols will exist and be precisely
defined, but currently they are not ready to go into the document
(assuming there isn't enough time left for this).
Basic language facilities that I think we can agree on by the end of
next week:
DEFCLASS
overall syntax
some of the options
some or all of the slot-options
class precedence rules
DEFGENERIC
overall syntax
some or all of the options
setf syntax
DEFMETHOD
"general" syntax, with space left for "classical" syntax
discrimination on required arguments
discrimination by classes
setf syntax
WITH
the only problem here is the name, which is too short
MAKE-INSTANCE
interface seen by the caller
we may have to defer the protocol for initialization methods
CLASS-OF
PRINT-OBJECT
DESCRIBE-OBJECT (can we name this DESCRIBE?)
DEFINE-METHOD-COMBINATION
we may have to postpone the details of this if we
have trouble agreeing
This leaves out a great deal, but should be enough to give people
a good idea of what is coming. At this point I think we should
leave out anything that we are having trouble converging on and
deal with it later. There will be a face to face meeting after
OOPSLA.
I'd like some feedback on this!
∂17-Sep-86 0856 Bobrow.pa@Xerox.COM Re: run-super
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 17 Sep 86 08:56:34 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 17 SEP 86 08:28:14 PDT
Date: 17 Sep 86 08:29 PDT
From: Bobrow.pa@Xerox.COM
Subject: Re: run-super
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Tue, 16 Sep 86 17:10 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CommonLoopsCore↑.pa@Xerox.COM
Message-ID: <860917-082814-7626@Xerox>
To simplify things, I removed :AROUND methods from this version, but
it would only take a few lines of code to put them back in if we wished
to do so.
I would like to see the addition for :around. (What do you think
changing ":around" to ":full-shadow"?) The particular feature I am interested
in is how you express the transformation of a form to a method. Is
this what your were referring to in:
;;;; This scheme uses more machine-dependencies to avoid
;;;; an extra level of lambda in the continuations.
That is, would you please fix up the following rough form of
the body of whopper-super-daemon combination.
What would it look like in Common Lisp? Thanks.
(STACK-LET ((*SUPERCLASS-CONTINUATIONS*
(LIST ,@(LOOP FOR METHOD IN (REST AROUND)
COLLECT `(FUNCTION ,METHOD)
COLLECT `(GET-FLAVOR-MAPPING-TABLE-FOR-INSTANCE
SELF ',(METHOD-FLAVOR METHOD)))
(make-method-from-form `(MULTIPLE-VALUE-PROG2 ...))
;;; the (MULTIPLE-VALUE-PROG2 ...) is the body found in the referenced message.
;;; this last form transforms that expression appropriately
)))
,(CALL-COMPONENT-METHOD (FIRST AROUND)))))
---
The important thing is the semantics of how RUN-SUPER and
method-combination fit together, which is:
all the :BEFORE methods are executed, most-specific first the
most specific primary method is executed, and supplies the value(s)
if it uses RUN-SUPER, that calls the next primary method,
and so on if RUN-SUPER exhausts the supply of primary methods, it
signals an error
all the :AFTER methods are executed, least-specific first
Shall we make this the default method-combination type, or does
anyone object? (Myself, I object to the name RUN-SUPER, and maybe we
can think of a more expressive name. If not, I can live with that one.)
I am happy with this as the default. I have no better name than run-super.
run-continuation is not semantically correct, and super has a history people
can relate to. I don't like the name "super-daemon" or even "daemon",
although history rgues for each of those. How about "simple-nested". or just
"nested" sincer the primary is nested in befores and afters, and run-super
does dynamically controlled nesting.
I would want to describe super-daemon in the spec in pieces.
The first would describe the specifcation of run-super alone as in Loops. Then
I would describe standar declarative method combination, and the interaction.
Finally, I would want to describe the method combination language that allows
these to be defined.
∂17-Sep-86 1036 Owners-CommonLoopsCore↑.pa@Xerox.COM Re: default optional arguments to a generic function
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 17 Sep 86 10:36:19 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 17 SEP 86 09:24:58 PDT
Redistributed: CommonLoopsCore↑.pa
Received: from Cabernet.ms by ArpaGateway.ms ; 17 SEP 86 09:24:43 PDT
Date: 17 Sep 86 09:21 PDT
Sender: Gregor.pa@Xerox.COM
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
Subject: Re: default optional arguments to a generic function
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Mon, 15 Sep 86 23:57 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CommonLoopsCore↑.pa@Xerox.COM
Message-ID: <860917-092458-7674@Xerox>
Unfortunately, the most important typo in my GFD#1 and GFD#2 message is
that I said I was leaning towards GFD#1. In fact, I lean towards #2.
GFD #1. the defaults from the defgeneric are used only for method
lookup. This is the kind I described above.
GFD #2. the defaults from the defgeneric are used for method lookup
and also passed to the method.
Doesn't your anecdote, which provides a good example of why two methods
should not be allowed to have different default value forms also support
GFD#2?
Date: Mon, 15 Sep 86 23:57 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Because of supplied-p parameters, I have to back off on this.
Supplied-p parameters are what confuse me too. Let me recap my thinking
on this.
I think of the arguments that the generic function accepts as being part
of its contract with the world. I think of any argument defaulting done
on those arguments as being part of that same contract (I lean towards
GFD#2).
But supplied-p information doesn't have anything to do with the
generic's contract with the world. Instead, supplied-p information
seems to me to be part of the generic functions contract with its
methods.
For me, the question about supplied-p arguments comes down to deciding
if these two contracts (generic---world, generic---methods) are the
*same*. In other words, the lambda list which appears in the defgeneric
clearly specifies the generic-world contract, the question is to what
extent does it also specify the generic-methods contract.
If we make the defgeneric completely specify both contracts, then the
defgeneric must say which arguments the methods can (and must) get
supplied-p information for.
If the defgeneric does not specify which arguments supplied-p
information is available for, but rather methods can ask for this
information on a per-method basis, I get confused.
To compare two lambda-lists for consistency, use the following
rules:
I want to try to re-write these rules to get rid of this EQUAL rule
about optional argument default value forms. In order to do that, I am
going to ignore the issue of supplied-p arguments (by not allowing
methods to get their hands on that information), and I am going to
assume that defgenerics are required. Note that my rules compare
defgeneric lambda lists to defmethod lambda lists.
1. The method must accept as required arguments the sum of the generic's
required optional and rest arguments.
2. &optional may not appear in a defmethod lambda list (an extension
would
allow this in the case where the defgeneric lambda list has neither
&key
nor &rest).
3. The method must accept the same keywords as the generic;
OR it can accept a subset of the ones in the defgeneric if it has
&allow-other-keys;
OR it can accept a superset of the ones in the defgeneric if the
defgeneric has &allow-other-keys.
4. &aux is not allowed in defgenerics, it is allowed in defmethods with
the
usual meaning.
Here are some examples:
(defgeneric draw (thing &optional (place *drawing-place*)))
(defmethod draw ((thing box) (place window)) ...)
(defmethod draw ((thing box) (place printer)) ...)
(defgeneric save (file &rest things))
(defmethod save ((file fancy-file) things) ...)
(defgeneric shape (thing &optional &key width height &allow-other-keys))
(defmethod shape ((r rectangle) &key width height) ...)
(defmethod shape ((c circle) &key radius) ...)
I another message, I will send a minimal proposal about defmethod
arguments which I think provides all the functionality we really
understand, and could be extended to any optional argument scheme we
eventually work out. If, by friday, we have settled on a scheme that
works for optional arguments I suggest we put this minimal proposal in
the spec to take to DC and OOPSLA.
∂17-Sep-86 1037 Kahn.pa@Xerox.COM Re: run-super
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 17 Sep 86 10:36:52 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 17 SEP 86 09:30:11 PDT
Date: 17 Sep 86 09:29 PDT
Sender: Kahn.pa@Xerox.COM
Subject: Re: run-super
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Tue, 16 Sep 86 17:10 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CommonLoopsCore↑.pa@Xerox.COM
From: Kahn.pa@Xerox.COM, Bobrow.pa@Xerox.COM
Message-ID: <860917-093011-7680@Xerox>
Regarding your code
(DEFINE-METHOD-COMBINATION :SUPER-DAEMON ()
...
;; Remove from dependencies the primary methods that cannot be reached
by RUN-SUPER
(SETQ PRIMARY (LOOP FOR METHOD IN PRIMARY
COLLECT METHOD
WHILE (METHOD-USES-RUN-SUPER METHOD)))
;; Return appropriate method combining form
...)
The last method in the primary list should be the first one that does
not use run-super. Only if all primary methods use run-super,
#'RUN-SUPER-EXHAUSTED must be inserted at the end of the list. It is
not an error for all primary methods to call run-super since in some
contexts the last primary method may be in another position in the
*SUPERCLASS-CONTINUATIONS* list. We might also then define run-super?
that returns NIL if the next continuation is #'RUN-SUPER-EXHAUSTED.
----- ken and danny
∂17-Sep-86 1037 Kahn.pa@Xerox.COM DEFCLASS should replace DEFSTRUCT
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 17 Sep 86 10:37:05 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 17 SEP 86 10:14:41 PDT
Date: 17 Sep 86 10:14 PDT
Sender: Kahn.pa@Xerox.COM
Subject: DEFCLASS should replace DEFSTRUCT
To: CommonLoopsCore↑.pa@Xerox.COM
cc: Kahn.pa@Xerox.COM
From: Ken Kahn <Kahn.pa@Xerox.COM>
Message-ID: <860917-101441-7733@Xerox>
A few months ago we believed that CommonLoops could just extend
DEFSTRUCT to deal with multiple inheritance and metaclasses. Then there
was this idea that DEFSTRUCT did some things poorly and we could do them
better in DEFCLASS. I am willing to agree to this if the spec proposes
that we flush DEFSTRUCT from Common Lisp and provide a DEFSTRUCT macro
for backwards compatibility that is mostly implemented in CommonLoops.
Why should anyone use DEFSTRUCT anymore? CommonLoops can provide a
STRUCTURE-CLASS metaclass that provides the same performance/capability
trade-offs as current DEFSTRUCT. The :TYPE option is weird but it could
still be supported, so that instances and "structures" built out of
lists and vectors can be made and accessed in a uniform manner
(MAKE-INSTANCE, GET-SLOT...). CLASS-OF won't work on them so one can't
put methods on them but that's the case in any case. 16 pages of the
Silver Book could go away if DEFSTRUCT is flushed. It would be a shame
if Common Lisp had to have two ways of defining structured objects, one
of which subsumes the other.
In Sonya's message about goals she states:
Simplicity The standard will specify just the language, not the
programming tools and interactive development
environment.
I think a more important aspect of Simplicity is that the language
specified not be unduely complex. Adding DEFCLASS and not removing
DEFSTRUCT clearly does add unneccessary complexity.
----- ken
∂17-Sep-86 1632 Gregor.pa@Xerox.COM Re: What we should agree on before OOPSLA
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 17 Sep 86 16:31:52 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 17 SEP 86 11:51:57 PDT
Date: 17 Sep 86 11:47 PDT
Sender: Gregor.pa@Xerox.COM
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
Subject: Re: What we should agree on before OOPSLA
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Tue, 16 Sep 86 20:50 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CommonLoopsCore↑.PA@Xerox.COM
Message-ID: <860917-115157-7842@Xerox>
This list looks pretty good to me.
I believe that Sonya's message is a good start for Part 1. I know that
we have some small changes we want to make to it. These will be in a
separate message.
I believe that the spec we are working on will satisfy Part 2, once we
work out the basic language facilities to be covered. I agree that we
can work out all the basic language details you included at the end of
your message. In addition, we may be able to come to some agreement on
optional arguments, I am not quite ready to quit on this.
You may be right that we should not include what we have so far for
meta-object protocols. You are certainly right that we don't have time
to tighten this up.
As I said yesterday, I hope to FEDx a spec to you by the end of the day
today.
In addition, I will try to send messages giving our current status for:
some defclass options which are unresolved,
with
describe-object
define-method-combination
I think these (except define-method-combination) should be easy to
resolve and can they be put in the spec easily.
∂17-Sep-86 1636 Gregor.pa@Xerox.COM The name of WITH
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 17 Sep 86 16:32:04 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 17 SEP 86 13:12:52 PDT
Date: 17 Sep 86 13:12 PDT
Sender: Gregor.pa@Xerox.COM
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
Subject: The name of WITH
To: CommonLoopsCore↑.pa@Xerox.COM
Message-ID: <860917-131252-7924@Xerox>
If people really think the name WITH is too short, then the name
WITH-SLOTS seems like the obvious best name to me.
∂17-Sep-86 1637 Owners-CommonLoopsCore↑.pa@Xerox.COM Re: Getting together to work
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 17 Sep 86 16:33:14 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 17 SEP 86 14:54:07 PDT
Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.pa
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
Xerox.COM ; 17 SEP 86 14:53:56 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 106466; Wed
17-Sep-86 17:41:42 EDT
Date: Wed, 17 Sep 86 17:41 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Getting together to work
To: CommonLoopsCore↑.pa@Xerox.COM
In-Reply-To: <860914-111121-5339@Xerox>
Message-ID: <860917174139.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 14 Sep 86 11:11 PDT
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
....
The conclusion, after various discussions, is that Sonya Keene, Dave
Moon, and Dan Weinreb will be in Palo Alto from Thursday October 2
through Sunday October 5. Exact times to be figured out later, but
basically all of Friday and Saturday will be available, possibly late
Thursday, and probably none of Sunday. I'll send mail with exact times
when we know the flight times.
This what Gregor proposed originally. I would have liked to have met
before OOPSLA instead, but it proved to be impossible. I assume we'll
have intense working sessions on the details of the standard for these
two days, with people from Lucid, Symbolics, and Xerox. Gregor, you're
going to arrange a meeting room and make sure people show up and stuff
like that, right?
∂17-Sep-86 1636 Bobrow.pa@Xerox.COM Proposed Goals (Statement for OOPSLA)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 17 Sep 86 16:32:14 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 17 SEP 86 11:32:16 PDT
Date: 17 Sep 86 11:33 PDT
From: Bobrow.pa@Xerox.COM
Subject: Proposed Goals (Statement for OOPSLA)
To: CommonLoopsCore↑.pa@Xerox.COM
cc: Bobrow.pa@Xerox.COM
Message-ID: <860917-113216-7821@Xerox>
Dick edited Sonya's version, then Danny and Gregor edited his to produce
this.
TOWARD A COMMON LISP STANDARD FOR OBJECT-ORIENTED PROGRAMMING
This brief paper summarizes the work that is now going on toward defining
a new Common Lisp standard for object-oriented programming.
HISTORY AND MOTIVATION
There is currently substantial experience with object-oriented programming
paradigms within a variety of contexts. The two groups have have the most
experience in this area are Symbolics and Xerox.
Flavors, an important object-oriented programming extension to Lisp, has
been in use for more than 7 years. Over that period many valuable lessons
have been learned about object-oriented programming in Lisp. In 1985,
Symbolics took these lessons to heart and designed New Flavors, which is a
compatible extension to Flavors.
Xerox has had more than 10 years of experience with object-oriented
programming, both within the Lisp tradition and within the Smalltalk
tradition. Over that period many lessons were learned, and in 1985 Xerox
began to design a new object-oriented programming extension to Common
Lisp, called CommonLoops.
In mid-1985 these two groups became aware of each other. These two
object-oriented extensions to Lisp had important similarities.
CommonLoops evolved to include some of the ideas in new Flavors.
Many people in the Common Lisp community now see a need for defining a
standard for object-oriented programming that would be part of Common
Lisp. The primary benefit of such a standard would be the ability to
write portable Common Lisp code in an object-oriented style.
At the Common Lisp committee meeting in Boston in December 1985, many
vendors of application software made it clear how important such a
standard is to them. Again at the ACM Conference on Lisp and Functional
Programming in Cambridge in August 1986, the same point was made.
After the ACM Conference there was a meeting of the Common Lisp
Object-oriented Programming Committee. A clear consensus was reached that
work should begin immediately to define a standard. Representatives from
Xerox, Lucid, Symbolics, LMI, HP, Sun, and the Japanese CommonLisp
committee supported this consensus.
A working group composed of representatives from Xerox and Symbolics met
after the ACM Conference; at the meeting this working group reached
agreement on several general goals.
In brief, the standard will be based on the meta-object framework of
CommonLoops, which allows experimentation with different philosophies of
object-oriented programming. Additional features from new Flavors will be
added to CommonLoops to flesh out the programmer interface; in particular,
a declarative method combination facility patterned after that in new
Flavors has been added to CommonLoops to create an extension to Common
Lisp that represents the best features of both systems.
PROGRESS IN AUGUST AND SEPTEMBER
During August and September, representatives from Xerox, Symbolics, and
Lucid began work on a draft specification of the standard. This working
group started with the basic programmer interface for defining new classes
and writing methods and generic functions. This work is ongoing, but a
draft of the programmer interface is available - the meta-object protocol
specification will be available soon.
GOALS FOR THE STANDARD
Some high-level goals were stated and agreed-upon:
Sound basis The standard will include the aspects of object-oriented
programming that are well-understood at this time. The
standard will omit ideas that are still subjects for
research.
Flexibility The meta-object protocol of the standard will offer a
flexible framework for other designers to implement
different schemes. This encourages exploration of
different styles of object-oriented programming.
Power The standard will offer the basic tools for writing
programs in an object-oriented style, and will be powerful
enough that it meets the needs of most programs. It should
not be necessary for programmers to extend the system to do
straightforward object-oriented programming.
Simplicity The standard will specify just the language, not the
programming tools and interactive development environment.
Compatibility It should be a convenient and simple procedure to translate
programs written in CommonLoops or New Flavors to the new
standard. We intend to provide tools that will perform the
translation automatically.
Implementation The standard will allow efficient implementation on stock
hardware as well as specialized machines.
FEATURES TO BE INCLUDED IN THE STANDARD
The following features wil be included in the standard.. This is not an
exhaustive list, but is intended to communicate some of the areas of
agreement that have been reached.
Generic functions
The standard will use the normal Lisp function-calling
syntax.
Class and Type Space Merging
Every object in the Lisp system has a class and hence can
be used to select methods.
Dispatching The standard will allow dispatching on the class of one
(classical methods) or more (multi-methods) arguments.
Multiple inheritance
Classes can be combined together freely; they
need not fit into a rigid hierarchy.
Meta-objects The standard defines objects for the major implementation
entities of the system to allow for extensibility.
Classes, methods, and generic functions all have
corresponding objects, organized by well-defined,
documented protocols.
Declarative Method Combination
Method selection and combination can be controlled
declaratively. Users can define new
method combination paradigms.
FUTURE PLANS
The working group is developing a draft specification for the standard.
The specification process will involve the community in the feedback
process.
Portable Common Loops will evolve to to track the new specification. This
portable implementation will enable the community to experiment with and
gain a deeper understanding of the ideas than is possible with only a
specification.
∂17-Sep-86 1636 Owners-CommonLoopsCore↑.pa@Xerox.COM Re: default optional arguments to a generic function
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 17 Sep 86 16:32:45 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 17 SEP 86 13:18:15 PDT
Return-Path: <Moon@ALDERAAN.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.pa
Received: from ALDERAAN.SCRC.Symbolics.COM ([192.10.41.109]) by
Xerox.COM ; 17 SEP 86 13:17:57 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 5208; Wed
17-Sep-86 16:14:22 EDT
Date: Wed, 17 Sep 86 16:15 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: default optional arguments to a generic function
To: CommonLoopsCore↑.pa@Xerox.COM
In-Reply-To:
<860916-103819-6832@Xerox>,<860916135909.5.GREGOR@AVALON.XEROX-PARC>
Message-ID: <860917161551.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 16 Sep 86 10:37 PDT
From: Bobrow.pa@Xerox.COM
GFD #1. the defaults from the defgeneric are used only for method
lookup. This is the kind I described above.
GFD #2. the defaults from the defgeneric are used for method lookup
and also passed to the method.
There is a fundamental conceptual difference. I think the notion of
supplying defaults is part of the contract between the generic function
and the world.
I agree.
This is an argument for GFD #1. We all seem to agree
that defmethods, if they specify optionals, must agree with the generic
function. If the EQUALS rule is used for defaults (I support this),
then I see no reason for the default forms to be evaluated twice.
This is an argument for GFD #2, I assume. In GFD #1 I don't see how to
avoid evaluating the default forms twice.
If
methods can have exactly the same supplied-p args as specified in the
generic function (no more, no less - just local renaming allowed) then
there is no penalty for passing supplied-p args to each method as
"required args". The calling sequence is uniform.
Supplied-p parameters are -not- part of the contract between the generic
function and the world, so requiring them to be the same in all methods
is a bit strange. It's possible that this is the price we have to pay
to make everything work, but it's ugly.
Given:
(defgeneric foo (x &optional y (z *v1* supplied-z)) ...)
then the following is legal
(defmethod foo ((x c1) &optional ((y c2)) (z *v1* my-supplied-z))) ..)
and the following are illegal
(defmethod foo ((x c1) &optional (y NIL supplied-y)(z *v1*
my-supplied-z))) ..)
(defmethod foo ((x c1) &optional y (z *v1* ))) ..)
One issue to be addressed is the following. If we insist on the EQUALS
rule, then if the default value form changes in the defgeneric, it must
be changed in all methods. This redundancy is bad design.
On the other hand, not having the default value lexically visible in the
method could be argued by some people as bad design. It's a difficult
situation.
To allow
arg-specification and supplied-p specification, I suggest another
keyword &optional-spec. Following &optional-spec can be
{varName|(varName arg-specifier [supplied-p-var])}*
where the interpretation is the obvious one, given in my message of last
week. The rule of supplied-p correspondence still holds, but no default
value form need be specified.
I think we need a better name than &optional-spec, but otherwise this
sounds reasonable, assuming that we want a way to do this. The message
from Gregor below raises questions about whether discriminating on
optional arguments is going to fly at all.
Date: Tue, 16 Sep 86 13:59 PDT
From: Gregor.pa@Xerox.COM
Subject: the kinds of method lookup people claim they want
I spent lunch today listening to people talk about the kinds of method
lookup which they would like to have CommonLoops support. I was struck
by the variety of things which people claimed would be natural or
convenient or even essential. By the end of lunch I was very confused
about what we should do about discriminating on optional arguments.
In the interest of confusing the rest of you, I thought I would collect a
list of all the cases of method definition people thought they would
want. Please add any other examples or potential screw cases.
NOTE: In each of these examples I have used some syntax and some
defining forms which I intend only to express the example. Do not
regard the syntax I have used as a proposal for how we should do
anything.
Case 1a. "draw-line"
draw-line takes an optional, the width of the line in device dependent
units. Because they are device dependent units, each individual method
would like to default this argument on its own.
(defmethod draw-line ((dev printer) p1 p2 &optional (width 7))
...)
(defmethod draw-line ((dev window) p1 p2 &optional (width 1))
...)
Case 1b.
Within case 1, some methods may want to take an extra argument. Also
see case 3 which is similar.
(defmethod draw-line ((d gray-display) p1 p2
&optional (width 3)
(gray *gray1*))
..)
The problem here is that the generic function doesn't have a consistent
contract. The meaning, or even the existence, of one argument depends
on the class of another argument. I don't see how a caller of draw-line
could operate without knowing the exact method that was going to be called.
From experience I know it's possible to have all sorts of arguments about
whether this is good or bad programming practice. In New Flavors, these
arguments were resolved in favor of consistency of contracts, rather than
the increased flexibility of different contracts for different methods,
but not everyone was happy.
The rules I proposed earlier for consistency of defgeneric and defmethod
lambda-lists, which Danny seems to agree with, would rule out both 1a and
1b. I don't know what to say about this; it may be impossible to please
all of the people all of the time.
Case 2. "draw (GFD#2)"
The generic function takes an optional argument. For all the methods,
the optional argument should default to the same value. In addition,
method lookup should be based on the value of the optional argument
(after defaulting) and the defaulted value should be passed in. This
corresponds to what I previously called GFD#2.
(defgeneric draw (thing &optional (place *draw-window*))
"Draw thing on place.")
(defmethod draw ((thing line) (place raster-display)) ...)
(defmethod draw ((thing line) (place vector-display)) ...)
People have also said that within the individual methods they would like
to have access to the supplied-p information for the optional argument.
Current ideas seem to be able to satisfy this one.
Case 3. "move"
A generic function (e.g. move) has only classical methods. Some of the
methods want to accept more arguments than others. For example: move
when then first argument is a block takes a position to move to, but
move when the first argument is a rabbit takes no extra arguments (the
rabbit will jump up and down).
(defmethod move ((b block) to-x to-y) ..)
(defmethod move ((r rabbit)) ..)
This is another case where the function isn't really generic, because
it can only be meaningfully called by someone who knows exactly which
method is being called.
Case 4. "Guy's proposal"
In this porposal, method lookup checks argument specifiers for only the
supplied arguments. When there are two arguments supplied, the most
specific of the two argument methods is called.
(defmethod foo (a b &optional (c x) (d y)) body)
is simply an abbreviation for
(defmethod foo (a b) (let ((c x) (d y)) body))
(defmethod foo (a b c) (let ((d y)) body))
(defmethod foo (a b c d) body)
So that:
(defmethod gls ((a boat) &optional ((p plane) *default*)) ..)
(defmethod gls ((a speed-boat)) ...)
(foo <a speed-boat>) ;runs method 2
(foo <a speed-boat> <a plane>) ;runs method 1
I hope this one has already been discredited as so confusing that no
one can cope with it.
-+-+-+-
Seeing all these different, and maybe not even mutually compatible,
things that people would like us to do, it is possible that we are
going to have to take the conservative approach and say that for now
we are only going to support discrimination on required arguments,
because discrimination on optional and keyword arguments is not yet
well-understood and there is not yet a concensus among users on which
to base a standard. GFD #2 can be achieved within this framework
by the expedient of defining an "interface function" that defaults
the arguments, for instance:
(defun draw (thing &optional (place *draw-window* place-supplied-p))
"Draw thing on place."
(draw-internal thing place place-supplied-p))
(defmethod draw-internal ((thing line) (place raster-display) place-supplied-p) ...)
(defmethod draw-internal ((thing line) (place vector-display) place-supplied-p) ...)
Flavors provides the feature that you don't have to make
up the auxiliary name draw-internal, which is confusing because
the externally visible interface is named draw but you put methods
on draw-internal. You do this by (translating out of the present
Flavors syntax, which is too biased against multimethods):
(defgeneric draw (thing &optional (place *draw-window* place-supplied-p))
"Draw thing on place."
(:method-arguments thing place place-supplied-p)
(:function
(funcall (generic draw) thing place place-supplied-p)))
(defmethod draw ((thing line) (place raster-display) place-supplied-p) ...)
(defmethod draw ((thing line) (place vector-display) place-supplied-p) ...)
∂17-Sep-86 1636 Owners-CommonLoopsCore↑.pa@Xerox.COM Re: run-super, whoppers, wrappers
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 17 Sep 86 16:32:30 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 17 SEP 86 13:18:01 PDT
Return-Path: <Moon@ALDERAAN.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.pa
Received: from ALDERAAN.SCRC.Symbolics.COM ([192.10.41.109]) by
Xerox.COM ; 17 SEP 86 13:17:41 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 5189; Wed
17-Sep-86 15:42:59 EDT
Date: Wed, 17 Sep 86 15:44 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: run-super, whoppers, wrappers
To: CommonLoopsCore↑.pa@Xerox.COM
In-Reply-To: <860917-082814-7626@Xerox>
Message-ID: <860917154410.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 17 Sep 86 08:29 PDT
From: Bobrow.pa@Xerox.COM
To simplify things, I removed :AROUND methods from this version, but
it would only take a few lines of code to put them back in if we wished
to do so.
I would like to see the addition for :around. (What do you think
changing ":around" to ":full-shadow"?)
The same as I thought on 11 September
(Message-ID: <860911172500.4.MOON@EUPHRATES.SCRC.Symbolics.COM>):
The name :full-shadow doesn't convey much meaning to my ear.
I'm not at all attached to the name "around". I was just using it in
the absence of anything better, since it was the name someone else (I
forget who) mentioned. Actually "around" seems to fit with "before" and
"after" better than "full-shadow". I'd say that "around" is a somewhat
clearer name than "full-shadow", which is miles better than "whopper".
If we can find a clearer name than any of these, I'm all for it.
I should mention again that these "around" methods are different from
whoppers, in that they are implemented by a particular type of method
combination, rather than being available automatically to all types of
method combination. If the standard said that all types of method
combination should support "around" methods, then either life would be
more difficult for a user wanting to define his own type of method
combination or we would have to subroutinize things so that it was
trivially easy for that user to include "around" support. I assume
that subroutinization is possible, but I haven't thought out the details.
I may not have made it clear that I don't care whether whoppers per se
are in the standard as long as there is something with equivalent
functionality in the standard. "Around" methods would suffice, I think.
Wrappers appear to be more powerful than "around" methods, at least in
terms of efficiency (eliminating function calls), but perhaps that can
be licked with an INLINE proclamation; I ought to think about this more.
For purposes of agreement before OOPSLA you don't need to think about
wrappers at all; I'll bring them up later if I don't convince myself
they aren't needed.
The particular feature I am interested
in is how you express the transformation of a form to a method.
The same way you always convert a form to a function, with lambda. The
code is at the end of this message.
Is
this what your were referring to in:
;;;; This scheme uses more machine-dependencies to avoid
;;;; an extra level of lambda in the continuations.
Not exactly. The two earlier implementations of run-super required an
extra lambda for every method called by run-super, for no good reason.
The body of the lambda was just a call-component-method of the method, I
think. This version eliminates those and calls the methods directly.
The cost of this efficiency improvement is that the RUN-SUPER macrolet
put into methods by TRANSFORM-SUPER-DAEMON-METHOD has to contain
additional hair to pass the arguments along, instead of just funcalling
the continuation with no arguments, and hence more of the Flavors
implementation is visible instead of abstracted out of sight; more about
this below.
The important thing is the semantics of how RUN-SUPER and
method-combination fit together, which is:
all the :BEFORE methods are executed, most-specific first the
most specific primary method is executed, and supplies the value(s)
if it uses RUN-SUPER, that calls the next primary method,
and so on if RUN-SUPER exhausts the supply of primary methods, it
signals an error
all the :AFTER methods are executed, least-specific first
Shall we make this the default method-combination type, or does
anyone object? (Myself, I object to the name RUN-SUPER, and maybe we
can think of a more expressive name. If not, I can live with that one.)
I am happy with this as the default. I have no better name than run-super.
run-continuation is not semantically correct, and super has a history people
can relate to.
Agreed.
I don't like the name "super-daemon" or even "daemon",
although history rgues for each of those. How about "simple-nested". or just
"nested" sincer the primary is nested in befores and afters, and run-super
does dynamically controlled nesting.
"super-daemon" was just a name I was using in the absence of a suggested
name and wasn't a proposal for the standard. I needed a name so I could
debug my code without clobbering the existing Flavors code. In the
standard there would be no need to have two distinct method-combination
types, one that does daemons but not run-super, and another that does
daemons and run-super, so fewer names would be required. "Nested"
doesn't convey any meaning to my ear. The way to really wimp out would
be to call this type of method-combination "default", since it will be
the default type. I'd rather have a more descriptive name, though. Any
ideas? My default assumption for right now is that it will be named
"daemon", but I'm not attached to that name. We don't actually need a
name for this in order to reach agreement on the list of things I
proposed last night as a reasonable agenda for the document to be handed
out at OOPSLA.
I would want to describe super-daemon in the spec in pieces.
The first would describe the specifcation of run-super alone as in Loops. Then
I would describe standar declarative method combination, and the interaction.
Finally, I would want to describe the method combination language that allows
these to be defined.
This sounds good. This is an extension of the way we do it now:
First we describe solitary methods so there is no combination issue.
Then we describe having one primary method shadow another. Here you
add run-super. Then we describe :before, :after, and now :around methods.
Then we describe other built-in types of method-combination. Then we
describe how to make your own types of method-combination.
Here is the revised code for the method-combination type. The only
other change is to make TRANSFORM-SUPER-DAEMON-METHOD treat around
methods the same as primary methods. Note that if I was going to
install this code I would first want to define some more abstractions,
similar to CALL-COMPONENT-METHOD, to hide the messy and
machine-dependent details of the method calling sequences. I didn't do
that in this version because I wanted to make it work first and then
think about what the appropriate abstractions would be. Another thing I
would want to do is to redo the STACK-LET since those lists are actually
constant, changing only when a change to the class structure occurs or a
method is redefined. For this version I construct the continuation list
every time, and then use STACK-LET instead of LET to eliminate the
consing, but it would be better to construct the list once and arrange
for it to be updated when the class structure changes. This is the sort
of place where I start wishing for meta-object protocols. I don't want
to spend time thinking about this until after OOPSLA, but for now I'm
assuming that the Common Lisp Classes version of this
DEFINE-METHOD-COMBINATION would be much less ugly, because it would be
built on top of those abstractions and protocols.
(DEFINE-METHOD-COMBINATION :SUPER-DAEMON ()
((AROUND "around" :EVERY :MOST-SPECIFIC-FIRST (:AROUND))
(BEFORE "before" :EVERY :MOST-SPECIFIC-FIRST (:BEFORE))
(PRIMARY "primary" :EVERY :MOST-SPECIFIC-FIRST () :DEFAULT)
(AFTER "after" :EVERY :MOST-SPECIFIC-LAST (:AFTER)))
(:ARGLIST IGNORE &REST ARGS)
(:METHOD-TRANSFORMER
;; Deal with run-super by transforming the method's arglist and body
(:METHOD-ARGLIST
(MULTIPLE-VALUE-SETQ (METHOD-ARGLIST METHOD-BODY)
(TRANSFORM-SUPER-DAEMON-METHOD FUNCTION-SPEC METHOD-ARGLIST METHOD-BODY)))
(:METHOD-BODY METHOD-BODY))
;; If there are no daemons, the code produced can be optimized
(UNLESS (OR BEFORE AFTER)
(SETQ PRIMARY (NCONC AROUND PRIMARY)
AROUND NIL))
;; Remove from dependencies the primary methods that cannot be reached by RUN-SUPER
(SETQ PRIMARY (LOOP FOR METHOD IN PRIMARY
COLLECT METHOD
WHILE (METHOD-USES-RUN-SUPER METHOD)))
;; Return appropriate method combining form
(IF (NULL AROUND)
`(MULTIPLE-VALUE-PROG2
,(CALL-COMPONENT-METHODS BEFORE)
,(COND ((NULL PRIMARY) `NIL)
((AND (NULL (REST PRIMARY))
(NOT (METHOD-USES-RUN-SUPER (FIRST PRIMARY))))
(CALL-COMPONENT-METHOD (FIRST PRIMARY))) ;Optimize single-method case
(T
;; Stash the machine-dependent information needed for run-super,
;; then call the first primary method, which will call the rest of them.
`(STACK-LET ((*SUPERCLASS-CONTINUATIONS*
(LIST ,@(LOOP FOR METHOD IN (REST PRIMARY)
COLLECT `(FUNCTION ,METHOD)
COLLECT `(GET-FLAVOR-MAPPING-TABLE-FOR-INSTANCE
SELF ',(METHOD-FLAVOR METHOD)))
#'RUN-SUPER-EXHAUSTED)))
,(CALL-COMPONENT-METHOD (FIRST PRIMARY)))))
,(CALL-COMPONENT-METHODS AFTER))
;; With both AROUND methods and daemons, need an internal method to call the daemons
;; and *SUPERCLASS-CONTINUATIONS* has to be bound around the whole thing
`(STACK-LET ((*SUPERCLASS-CONTINUATIONS*
(LIST ,@(LOOP FOR METHOD IN (REST AROUND)
COLLECT `(FUNCTION ,METHOD)
COLLECT `(GET-FLAVOR-MAPPING-TABLE-FOR-INSTANCE
SELF ',(METHOD-FLAVOR METHOD)))
;;--- The arglist of this lambda should be hidden by an
;;--- abstraction, which would also allow it to not need
;;--- to use &REST all the time
#'(LAMBDA (SELF SELF-MAPPING-TABLE .GENERIC. &REST ,ARGS)
(MULTIPLE-VALUE-PROG2
,(CALL-COMPONENT-METHODS BEFORE)
,(CALL-COMPONENT-METHOD (FIRST PRIMARY))
,(CALL-COMPONENT-METHODS AFTER)))
SELF-MAPPING-TABLE
,@(LOOP FOR METHOD IN (REST PRIMARY)
COLLECT `(FUNCTION ,METHOD)
COLLECT `(GET-FLAVOR-MAPPING-TABLE-FOR-INSTANCE
SELF ',(METHOD-FLAVOR METHOD))))))
,(CALL-COMPONENT-METHOD (FIRST AROUND)))))
∂17-Sep-86 1636 Gregor.pa@Xerox.COM required-xxx options to defclass
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 17 Sep 86 16:32:57 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 17 SEP 86 13:26:58 PDT
Date: 17 Sep 86 13:26 PDT
Sender: Gregor.pa@Xerox.COM
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
Subject: required-xxx options to defclass
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CommonLoopsCore↑.pa@Xerox.COM
Message-ID: <860917-132658-7944@Xerox>
This seems to be an issue that remains to be worked out about defclass.
Until yesterday, I was the only west coast supporter of the
:required-methods etc. options to defclass. But I have finally given in
and conceded that maybe these should not be in the standard.
I had been able to convince people that these options were not, in fact,
merely a programming environment feature. But I finally succumbed to
the argument that:
These options are just hack implementations of something which
*protocols* would do right. Given that we don't have protocols, and we
don't want to clutter the spec with hacks, we should not include these
options. Then, when we do figure out how to do protocols "right", there
won't be these old, obsolete required-xxx options hanging around.
How do you feel about not having :required-xxx options in the standard?
∂17-Sep-86 2028 Owners-CommonLoopsCore↑.pa@Xerox.COM DEFCLASS should replace DEFSTRUCT
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 17 Sep 86 20:28:46 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 17 SEP 86 16:51:18 PDT
Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.pa
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
Xerox.COM ; 17 SEP 86 16:50:58 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 106567; Wed
17-Sep-86 19:49:30 EDT
Date: Wed, 17 Sep 86 19:49 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: DEFCLASS should replace DEFSTRUCT
To: CommonLoopsCore↑.pa@Xerox.COM
In-Reply-To: <860917-101441-7733@Xerox>
Message-ID: <860917194955.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 17 Sep 86 10:14 PDT
From: Ken Kahn <Kahn.pa@Xerox.COM>
A few months ago we believed that CommonLoops could just extend
DEFSTRUCT to deal with multiple inheritance and metaclasses. Then there
was this idea that DEFSTRUCT did some things poorly and we could do them
better in DEFCLASS. I am willing to agree to this if the spec proposes
that we flush DEFSTRUCT from Common Lisp and provide a DEFSTRUCT macro
for backwards compatibility that is mostly implemented in CommonLoops.
Why should anyone use DEFSTRUCT anymore?
I believe this should be proposed as a separate standardization item.
I don't think the object-oriented programming standard should stand or
fall on the basis of irrelevant considerations such as whether someone
out there is particularly attached to DEFSTRUCT.
∂17-Sep-86 2029 Owners-CommonLoopsCore↑.pa@Xerox.COM Re: run-super
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 17 Sep 86 20:28:52 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 17 SEP 86 17:02:09 PDT
Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.pa
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
Xerox.COM ; 17 SEP 86 17:01:49 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 106573; Wed
17-Sep-86 20:00:05 EDT
Date: Wed, 17 Sep 86 20:00 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: run-super
To: CommonLoopsCore↑.pa@Xerox.COM
In-Reply-To: <860917-093011-7680@Xerox>
Message-ID: <860917200030.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 17 Sep 86 09:29 PDT
From: Kahn.pa@Xerox.COM, Bobrow.pa@Xerox.COM
Regarding your code
(DEFINE-METHOD-COMBINATION :SUPER-DAEMON ()
...
;; Remove from dependencies the primary methods that cannot be reached
by RUN-SUPER
(SETQ PRIMARY (LOOP FOR METHOD IN PRIMARY
COLLECT METHOD
WHILE (METHOD-USES-RUN-SUPER METHOD)))
;; Return appropriate method combining form
...)
The last method in the primary list should be the first one that does
not use run-super.
That's exactly what that code does. You may have been misled by thinking
that LOOP executes its clauses out of order, the way Interlisp FOR does.
The above LOOP stops -after- collecting the method for which
METHOD-USES-RUN-SUPER is false.
Only if all primary methods use run-super,
#'RUN-SUPER-EXHAUSTED must be inserted at the end of the list.
That's true, the list could be shortened by one element in the case
where the last element is unreachable. I'll put a comment in my copy of
that program saying that it should be optimized. Also, I forgot to
include #'RUN-SUPER-EXHAUSTED at the end of the list in the
around-method case, in the revised version of the code I mailed out
earlier today.
It is
not an error for all primary methods to call run-super since in some
contexts the last primary method may be in another position in the
*SUPERCLASS-CONTINUATIONS* list.
That's a good point. That sinks my idea of detecting the
RUN-SUPER-EXHAUSTED at compile time instead of at run time; good, I can
stop worrying about that.
We might also then define run-super?
that returns NIL if the next continuation is #'RUN-SUPER-EXHAUSTED.
Yes, we could do that. Note that standard Common Lisp functions aren't
allowed to have question marks in their names, but I'm sure we could think
of a better name.
∂17-Sep-86 2029 Masinter.pa@Xerox.COM Re: DEFCLASS should replace DEFSTRUCT
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 17 Sep 86 20:28:58 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 17 SEP 86 19:52:38 PDT
Date: 17 Sep 86 19:50 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: DEFCLASS should replace DEFSTRUCT
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Wed, 17 Sep 86 19:49 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CommonLoopsCore↑.pa@Xerox.COM
Message-ID: <860917-195238-8313@Xerox>
I disagree (rather violently). I think that the reason that CommonLoops
was originally acceptable to a large class of people was that it did not
add substantially to the complexity of the Language. The acceptability
of CommonLoops partially on that principle, and any movement away from
it risks losing it.
It is certainly not a separable consideration.
Similarly, a syntax where DEFUN was syntactically compatible with
DEFMETHOD (or whatever its method alias is called) is another important
simplification of Common Lisp. Making a large number of alternative
forms, adding DEFGENERIC, and number of the other proposed extentions
which have been added by this negotiating group are a potentially
drastic movement away from the simplicity in the original proposal.
I had been misled into believing the discussions on CommonLoopsCore↑ was
an attempt to do some minor tuning on the way that metaclasses were set
up and initialization. Into the conversation for a couple of days, I've
found that things have drifted radically away from what we and many
others have agreed to support.
/sub
"commonloopscore↑.pa"@xerox
DEFCLASS should replace DEFSTRUCT
I bow to those who use mailers that sort mail according to subject:
My message is responsive to the discussion which has gone on under
this subject line, but the contents of my remarks and of the remarks
to which I reply bear no semantic relationship to the subject line.
There indeed was a simplicity in the early CommonLoops proposal, but the
simplicity was the simplicity of a naive proposal. In particular, the
use of Defmethod as a vague replacement for Defun to create a cloud of
functions that are invoked variously misses the goal of a clearly understood
construct. What precisely is the contract between this cloud and the outside
world? How does this cloud relate to Lisp functions? If you can FUNCALL this
cloud, can you affect it by affecting the thing that sits in the symbol-function
cell of a symbol? Simply stated, is the cloud a first-class object, or is it
like the heap?
The `negotiating' group is doing more than negotiating: It is attempting to
bring some design sense into the picture. The early CommonLoops proposal
was more like a slogan than a well-designed system.
-rpg-
∂17-Sep-86 2031 Owners-CommonLoopsCore↑.pa@Xerox.COM Proposed Goals (Statement for OOPSLA)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 17 Sep 86 20:29:10 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 17 SEP 86 19:54:42 PDT
Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.pa
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
Xerox.COM ; 17 SEP 86 19:53:16 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 106633; Wed
17-Sep-86 22:51:47 EDT
Date: Wed, 17 Sep 86 22:52 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Proposed Goals (Statement for OOPSLA)
To: CommonLoopsCore↑.pa@Xerox.COM
In-Reply-To: <860917-113216-7821@Xerox>
Message-ID: <860917225211.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 17 Sep 86 11:33 PDT
From: Bobrow.pa@Xerox.COM
Dick edited Sonya's version, then Danny and Gregor edited his to produce
this.
All of the changes are okay with me, except that I have problems with the
style of this one:
In brief, the standard will be based on the meta-object framework of
CommonLoops, which allows experimentation with different philosophies of
object-oriented programming. Additional features from new Flavors will
be added to CommonLoops to flesh out the programmer interface; in
particular, a declarative method combination facility patterned after
that in new Flavors has been added to CommonLoops to create an extension
to Common Lisp that represents the best features of both systems.
This confuses what has been done to CommonLoops so far, adding some
Flavors ideas, with the definition of the standard. Those are two
different things. I think I understand what you're trying to get at
with this improvement of the earlier version of this paragraph, and I'd
like to propose this revision:
In brief, the standard will be based on the meta-object framework of
CommonLoops, which allows experimentation with different philosophies of
object-oriented programming. The programmer interface on top of this
framework will combine the most useful features of CommonLoops and New
Flavors, such as multimethods from CommonLoops and declarative method
combination from Flavors. The standard will be an extension to Common
Lisp that incorporates the best features of both systems.
∂17-Sep-86 2224 Owners-CommonLoopsCore↑.pa@Xerox.COM The name of WITH
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 17 Sep 86 22:24:06 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 17 SEP 86 20:37:55 PDT
Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.pa
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
Xerox.COM ; 17 SEP 86 20:37:44 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 106656; Wed
17-Sep-86 23:34:14 EDT
Date: Wed, 17 Sep 86 23:34 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: The name of WITH
To: CommonLoopsCore↑.pa@Xerox.COM
In-Reply-To: <860917-131252-7924@Xerox>
Message-ID: <860917233439.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 17 Sep 86 13:12 PDT
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
If people really think the name WITH is too short, then the name
WITH-SLOTS seems like the obvious best name to me.
That sounds good to me too.
∂17-Sep-86 2224 Owners-CommonLoopsCore↑.pa@Xerox.COM required-xxx options to defclass
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 17 Sep 86 22:24:14 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 17 SEP 86 20:55:02 PDT
Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.pa
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
Xerox.COM ; 17 SEP 86 20:54:52 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 106667; Wed
17-Sep-86 23:52:13 EDT
Date: Wed, 17 Sep 86 23:52 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: required-xxx options to defclass
To: CommonLoopsCore↑.pa@Xerox.COM
In-Reply-To: <860917-132658-7944@Xerox>
Message-ID: <860917235226.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 17 Sep 86 13:26 PDT
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
These options are just hack implementations of something which
*protocols* would do right. Given that we don't have protocols, and we
don't want to clutter the spec with hacks, we should not include these
options. Then, when we do figure out how to do protocols "right", there
won't be these old, obsolete required-xxx options hanging around.
How do you feel about not having :required-xxx options in the standard?
I'm not convinced that protocols will eliminate the :required-xxx
options. However, I agree that the "sound basis" item in our professed
statement of goals requires that things we suspect, after sufficient
discussion, are not well understood should not be included.
The question, then, is whether these are sufficiently indispensable to
users to justify including them anyway (the "power" and "compatibility"
goals). In this case I think the answer is no. So let's leave these
out of the standard for now.
∂18-Sep-86 0625 Owners-CommonLoopsCore↑.pa@Xerox.COM The name of WITH
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 18 Sep 86 06:25:36 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 18 SEP 86 05:29:12 PDT
Return-Path: <skeene@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.pa
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
Xerox.COM ; 18 SEP 86 05:29:01 PDT
Received: from JUNCO.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 106773; Thu
18-Sep-86 08:19:01 EDT
Date: Thu, 18 Sep 86 08:17 EDT
From: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
Subject: The name of WITH
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CommonLoopsCore↑.pa@Xerox.COM
In-Reply-To: <860917233439.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <860918081727.4.SKEENE@JUNCO.SCRC.Symbolics.COM>
Line-fold: No
Date: Wed, 17 Sep 86 23:34 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Date: 17 Sep 86 13:12 PDT
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
If people really think the name WITH is too short, then the name
WITH-SLOTS seems like the obvious best name to me.
That sounds good to me too.
Does WITH-SLOTS only give you variables for each slot, or does it also
give you a "SELF" variable for the object itself? If it also provides
a variable for the object, maybe WITH-INSTANCE would be a better name.
∂18-Sep-86 0811 Owners-CommonLoopsCore↑.pa@Xerox.COM Proposed Goals (Statement for OOPSLA)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 18 Sep 86 08:11:33 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 18 SEP 86 07:43:05 PDT
Return-Path: <skeene@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.pa
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
Xerox.COM ; 18 SEP 86 07:42:09 PDT
Received: from JUNCO.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 106864; Thu
18-Sep-86 10:34:54 EDT
Date: Thu, 18 Sep 86 10:33 EDT
From: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Proposed Goals (Statement for OOPSLA)
To: Bobrow.pa@Xerox.COM
cc: CommonLoopsCore↑.pa@Xerox.COM
In-Reply-To: <860917-113216-7821@Xerox>
Message-ID: <860918103320.8.SKEENE@JUNCO.SCRC.Symbolics.COM>
Line-fold: No
Date: 17 Sep 86 11:33 PDT
From: Bobrow.pa@Xerox.COM
Dick edited Sonya's version, then Danny and Gregor edited his to produce
this.
Thanks for your quick response on this. I've revised the text of this
statement to include your changes (except for one paragraph), and I also
corrected a few typos in your version. Anything that I changed from
your version is enclosed in *asterisks* below.
Moon has sent another version of the paragraph in question for you to
comment on. It's also included here.
HISTORY AND MOTIVATION
There is currently substantial experience with object-oriented
programming paradigms within a variety of contexts. The two groups
*have have* the most experience in this area are Symbolics and Xerox.
Only one "have"
Flavors, an important object-oriented programming extension to Lisp,
has been in use for more than 7 years. Over that period many valuable
lessons
have been learned about object-oriented programming in Lisp. In 1985,
Symbolics took these lessons to heart and designed New Flavors, which
is a compatible extension to Flavors.
Xerox has had more than 10 years of experience with object-oriented
programming, both within the Lisp tradition and within the Smalltalk
tradition. Over that period many lessons were learned, and in 1985
Xerox
began to design a new object-oriented programming extension to Common
Lisp, called CommonLoops.
In mid-1985 these two groups became aware of each other. These
two object-oriented extensions to Lisp had important similarities.
CommonLoops evolved to include some of the ideas in *new Flavors*.
Capitalize "New Flavors".
Many people in the Common Lisp community now see a need for defining a
standard for object-oriented programming that would be part of Common
Lisp. The primary benefit of such a standard would be the ability to
write portable Common Lisp code in an object-oriented style.
At the Common Lisp committee meeting in Boston in December 1985, many
vendors of application software made it clear how important such a
standard is to them. Again at the ACM Conference on Lisp and Functional
Programming in Cambridge in August 1986, the same point was made.
After the ACM Conference there was a meeting of the Common Lisp
Object-oriented Programming Committee. A clear consensus was reached
that
work should begin immediately to define a standard. Representatives
from Xerox, Lucid, Symbolics, LMI, HP, Sun, and the Japanese CommonLisp
committee supported this consensus.
A working group composed of representatives from Xerox and Symbolics met
after the ACM Conference; at the meeting this working group reached
agreement on several general goals.
*In brief, the standard will be based on the meta-object framework of
CommonLoops, which allows experimentation with different philosophies of
object-oriented programming. Additional features from new Flavors will
be added to CommonLoops to flesh out the programmer interface; in
particular, a declarative method combination facility patterned after
that in new Flavors has been added to CommonLoops to create an extension
to Common Lisp that represents the best features of both systems.*
We prefer the paragraph below, because it makes it clear that the new
thing isn't CommonLoops:
"In brief, the standard will be based on the meta-object framework of
CommonLoops, which allows experimentation with different philosophies of
object-oriented programming. The programmer interface on top of this
framework will combine the most useful features of CommonLoops and New
Flavors, such as multimethods from CommonLoops and declarative method
combination from Flavors. The standard will be an extension to Common
Lisp that incorporates the best features of both systems."
PROGRESS IN AUGUST AND SEPTEMBER
During August and September, representatives from Xerox, Symbolics, and
Lucid began work on a draft specification of the standard. This working
group started with the basic programmer interface for defining new
classes
and writing methods and generic functions. *This work is ongoing, but a
draft of the programmer interface is available - the meta-object
protocol specification will be available soon.*
Let's make that two complete sentences: "This work is ongoing, but a
draft of the programmer interface is available. The meta-object
protocol specification will be available soon."
GOALS FOR THE STANDARD
Some high-level goals were stated and agreed-upon:
Sound basis The standard will include the aspects of object-oriented
programming that are well-understood at this time. The
standard will omit ideas that are still subjects for
research.
Flexibility The meta-object protocol of the standard will offer a
flexible framework for other designers to implement
different schemes. This encourages exploration of
different styles of object-oriented programming.
Power The standard will offer the basic tools for writing
programs in an object-oriented style, and will be
powerful
enough that it meets the needs of most programs. It
should
not be necessary for programmers to extend the system to
do
straightforward object-oriented programming.
Simplicity The standard will specify just the language, not the
programming tools and interactive development
environment.
Compatibility It should be a convenient and simple procedure to
translate
programs written in CommonLoops or New Flavors to the
new
standard. We intend to provide tools that will perform
the
translation automatically.
Implementation The standard will allow efficient implementation on
stock
hardware as well as specialized machines.
FEATURES TO BE INCLUDED IN THE STANDARD
The following features *wil be* included in the standard.. This is not an
"will be"
exhaustive list, but is intended to communicate some of the areas of
agreement that have been reached.
Generic functions
The standard will use the normal Lisp function-calling
syntax.
Class and Type Space Merging
Every object in the Lisp system has a class and hence
can
be used to select methods.
Dispatching The standard will allow dispatching on the class of one
(classical methods) or more (multi-methods) arguments.
Multiple inheritance
Classes can be combined together freely; they
need not fit into a rigid hierarchy.
Meta-objects The standard defines objects for the major
implementation
entities of the system to allow for extensibility.
Classes, methods, and generic functions all have
corresponding objects, organized by well-defined,
documented protocols.
Declarative Method Combination
Method selection and combination can be controlled
declaratively. Users can define new
method combination paradigms.
FUTURE PLANS
The working group is developing a draft specification for the
standard. The specification process will involve the community in the
feedback process.
*Portable Common Loops will evolve to to track the new specification.
This portable implementation will enable the community to experiment
with and
gain a deeper understanding of the ideas than is possible with only a
specification.*
A. Only one "to".
B. I prefer my original text "We wil produce a portable implementation
by evolving Portable Common Loops..." instead of your "Portable Common
Loops will evolve..." PCL isn't going to evolve spontaneously.
How about saying "Xerox will update Portable Common Loops to track the
new specification?"
C. Let's recast that last sentence to take the distracting clause out of the
middle.
That paragraph turns into:
"Xerox will update Portable Common Loops to track the new specification.
By experimenting with the portable implementation, the community can
gain a deeper understanding of the ideas than would be possible by
reading the specification alone."
/sub
"commonloopscore↑.pa"@xerox
Proposed Goals (Statement for OOPSLA)
Sonya's improvements are generally good. I changed her original
sentence
``We will produce a portable implementation by evolving Portable
Common Loops...''
because it can parse in a funny way if you use a slightly less primary
definition of `evolve' than `to exhibit or produce through evolution.'
The definition is `to emit' as in `to evolve gases.' I parsed it as
it would appear in this sentence:
``Danny Bobrow ate a large plate of refried beans last night, went
back to PARC, and accidentally evolved Portable Common Loops. He
apologized profusely for his bad manners.''
Your rephrasing is better than mine, but it does commit Xerox to doing
the work of updating PCL, which they may elect not to do.
One reason for the phrasing of the pedigree paragraph is to emphasize
that the influence of New Flavors on CommonLoops has been going on for
over a year, and that the proposed standard will be more nearly along
the line of evolution, if you will, of CommonLoops as influenced by
New Flavors than a fresh merging of the two systems off the lines of
either. That is, the proposed standard will not be especially like
the CommonLoops of a year ago, but it will be very much like the
CommonLoops of today, because a movement towards New Flavors has
already taken place.
The reason for wanting to reason this way is to give the community
some sense of continuity over the past year. People will possibly rest
more comfortably if they believe that the ideas have developed over a
year's time rather than over a month's time.
The proposed standard will be what it will be, and its pedigree will
be of interest only to historians, and those historians will be able
to see the family lines accurately.
-rpg-
∂18-Sep-86 0900 Bobrow.pa@Xerox.COM Re: The name of WITH
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 18 Sep 86 08:59:51 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 18 SEP 86 08:26:50 PDT
Date: 18 Sep 86 08:28 PDT
From: Bobrow.pa@Xerox.COM
Subject: Re: The name of WITH
In-reply-to: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Thu, 18 Sep 86 08:17 EDT
To: skeene@STONY-BROOK.SCRC.Symbolics.COM
cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, CommonLoopsCore↑.pa@Xerox.COM
Message-ID: <860918-082650-8617@Xerox>
Does WITH-SLOTS only give you variables for each slot, or does it
also give you a "SELF" variable for the object itself? If it
also
provides a variable for the object, maybe WITH-INSTANCE would be a
better name.
In the standard syntax for methods, there is no special name self. The
user chooses the name for an object. WITH-SLOTS allows you access slots
using a variable name. For example,
(defclass point () ((x 0) (y 0)) (accessors-with-prefix point-))
(defmethod move ((p point) dx dy)
(with-slots (p) ;; p is known to be a point from the method-signature
(setq x (+ x dx) y (+ y dy))))
In this example, p could have been used to refer to the point itself.
(+ x dx) expands to
(+ (point-x p) dx) etc.
Using %with-slots
(%with-slots (p) (setq x (+ x dx) y (+ y dy))))
(+ x dx) expands to
(+ (get-slot p x) dx)
The syntax of with-slots is:
(with-slots ({var-name|(var-name var-prefix [class-name]}*) . body)
In the simple case, where only a var-name is used, it is assumed that
the class of the named variable can be determined from the method
signature. Slot-names from the class can be used to access slots of the
object bound to var-name. This is illustrated above.
If two or more var-names are given, then they must have disjoint sets of
names for slots to avoid ambiguity of reference. (but see var-prefix
below). In such a case an error is signalled.
If var-prefix is provided, then references to any slot <slot1> can be
made using the symbol (concat var-prefix <slot1>). This allows easy
reference to two objects of the same class. For example,
(defmethod make-same-height ((p1 point) (p2 point))
;;; set the y coord of p1 to the y of p2, its reference.
;;; slots of p1 are accessed using the slot names
;;; slots of p2 are accessed using ref-<slot-name>
(with-slots (p1 (p2 ref-)) (setq y ref-y)))
Under some circumstances, the class of an object will not be computable
from the method signature, but can be specified by the user.
For example,
(defmethod make-horizontal ((l line))
(let((left (left-point l)) (right (right-point l)))
(with-slots ((left left- point)(right right- point))
(setq left-y right-y))))
These last examples are silly in that one would not go to this trouble
to reference a single variable. But with-slots is very convenient if
you want to do many references.
The scope of these names is lexical (as is obvious from their
trranslation).
%with-slots is identical to with, except that
with-slots expands slot references to access functions and
%with-slots expands slot references to direct accesses
-- danny
∂18-Sep-86 0900 Bobrow.pa@Xerox.COM Re: DEFCLASS should replace DEFSTRUCT
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 18 Sep 86 08:59:59 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 18 SEP 86 08:36:41 PDT
Date: 18 Sep 86 08:38 PDT
From: Bobrow.pa@Xerox.COM
Subject: Re: DEFCLASS should replace DEFSTRUCT
In-reply-to: Masinter.pa's message of 17 Sep 86 19:50 PDT
To: Masinter.pa@Xerox.COM
cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, CommonLoopsCore↑.pa@Xerox.COM
Message-ID: <860918-083641-8627@Xerox>
I think that the reason that CommonLoops was originally acceptable
to a large class of people was that it did not add substantially to
the complexity of the Language. The acceptability of CommonLoops
partially on that principle, and any movement away from it
risks losing it.
I think simplifying Common Lisp is an admirable goal, and when this
standard is agreed on, I think the Common Lips community can take on
itself the task of redefining old features on top of the new. Not only
do I think that defstruct should go away, but the sequence functions
should be made methods, errors should use objects, the type system
should be described in terms of predications, classes, etc. This
layering of Common Lisp would make a lot cleaner language. Let us put
these items on our agenda.
BUT we have not yet got an object standard!!!! We should keep those
goals in the back of our mind, and try to enable such folding. The job
in front of us at the moment is to ensure we have a useful object
standard.
-- danny
∂18-Sep-86 1100 Owners-commonloopscore↑.pa@Xerox.COM DEFCLASS should replace DEFSTRUCT
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 18 Sep 86 10:59:08 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 18 SEP 86 10:16:46 PDT
Return-Path: <RPG@SAIL.STANFORD.EDU>
Redistributed: commonloopscore↑.pa
Received: from SAIL.STANFORD.EDU (SU-AI.ARPA) by Xerox.COM ; 18 SEP 86
10:16:32 PDT
Date: 18 Sep 86 10:16 PDT
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Subject: DEFCLASS should replace DEFSTRUCT
To: commonloopscore↑.pa@Xerox.COM
Message-ID: <860918-101646-8740@Xerox>
I bow to those who use mailers that sort mail according to subject:
My message is responsive to the discussion which has gone on under
this subject line, but the contents of my remarks and of the remarks
to which I reply bear no semantic relationship to the subject line.
There indeed was a simplicity in the early CommonLoops proposal, but the
simplicity was the simplicity of a naive proposal. In particular, the
use of Defmethod as a vague replacement for Defun to create a cloud of
functions that are invoked variously misses the goal of a clearly understood
construct. What precisely is the contract between this cloud and the outside
world? How does this cloud relate to Lisp functions? If you can FUNCALL this
cloud, can you affect it by affecting the thing that sits in the symbol-function
cell of a symbol? Simply stated, is the cloud a first-class object, or is it
like the heap?
The `negotiating' group is doing more than negotiating: It is attempting to
bring some design sense into the picture. The early CommonLoops proposal
was more like a slogan than a well-designed system.
-rpg-
∂18-Sep-86 1100 Owners-commonloopscore↑.pa@Xerox.COM Proposed Goals (Statement for OOPSLA)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 18 Sep 86 10:59:02 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 18 SEP 86 10:02:49 PDT
Return-Path: <RPG@SAIL.STANFORD.EDU>
Redistributed: commonloopscore↑.pa
Received: from SAIL.STANFORD.EDU (SU-AI.ARPA) by Xerox.COM ; 18 SEP 86
10:02:32 PDT
Date: 18 Sep 86 10:01 PDT
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Subject: Proposed Goals (Statement for OOPSLA)
To: commonloopscore↑.pa@Xerox.COM
Message-ID: <860918-100249-8718@Xerox>
Sonya's improvements are generally good. I changed her original
sentence
``We will produce a portable implementation by evolving Portable
Common Loops...''
because it can parse in a funny way if you use a slightly less primary
definition of `evolve' than `to exhibit or produce through evolution.'
The definition is `to emit' as in `to evolve gases.' I parsed it as
it would appear in this sentence:
``Danny Bobrow ate a large plate of refried beans last night, went
back to PARC, and accidentally evolved Portable Common Loops. He
apologized profusely for his bad manners.''
Your rephrasing is better than mine, but it does commit Xerox to doing
the work of updating PCL, which they may elect not to do.
One reason for the phrasing of the pedigree paragraph is to emphasize
that the influence of New Flavors on CommonLoops has been going on for
over a year, and that the proposed standard will be more nearly along
the line of evolution, if you will, of CommonLoops as influenced by
New Flavors than a fresh merging of the two systems off the lines of
either. That is, the proposed standard will not be especially like
the CommonLoops of a year ago, but it will be very much like the
CommonLoops of today, because a movement towards New Flavors has
already taken place.
The reason for wanting to reason this way is to give the community
some sense of continuity over the past year. People will possibly rest
more comfortably if they believe that the ideas have developed over a
year's time rather than over a month's time.
The proposed standard will be what it will be, and its pedigree will
be of interest only to historians, and those historians will be able
to see the family lines accurately.
-rpg-
∂18-Sep-86 1100 Owners-CommonLoopsCore↑.pa@Xerox.COM Re: The name of WITH
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 18 Sep 86 10:59:16 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 18 SEP 86 10:57:33 PDT
Return-Path: <skeene@ALDERAAN.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.pa
Received: from ALDERAAN.SCRC.Symbolics.COM ([192.10.41.109]) by
Xerox.COM ; 18 SEP 86 10:57:06 PDT
Received: from JUNCO.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM
via CHAOS with CHAOS-MAIL id 5379; Thu 18-Sep-86 13:52:29 EDT
Date: Thu, 18 Sep 86 13:51 EDT
From: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: The name of WITH
To: Bobrow.pa@Xerox.COM
cc: skeene@STONY-BROOK.SCRC.Symbolics.COM,
Moon@STONY-BROOK.SCRC.Symbolics.COM, CommonLoopsCore↑.pa@Xerox.COM
In-Reply-To: <860918-082650-8617@Xerox>
Message-ID: <860918135152.0.SKEENE@JUNCO.SCRC.Symbolics.COM>
Line-fold: No
Date: 18 Sep 86 08:28 PDT
From: Bobrow.pa@Xerox.COM
Thanks for the information on WITH-SLOTS. I have two questions.
Does WITH-SLOTS only give you variables for each slot, or does it
also give you a "SELF" variable for the object itself? If it
also
provides a variable for the object, maybe WITH-INSTANCE would be a
better name.
In the standard syntax for methods, there is no special name self. The
user chooses the name for an object. WITH-SLOTS allows you access slots
using a variable name. For example,
(defclass point () ((x 0) (y 0)) (accessors-with-prefix point-))
If the class of point had been defined without specifying the
:accessors-with-prefix option, what happens when you define (or run?)
the method below?
(defmethod move ((p point) dx dy)
(with-slots (p) ;; p is known to be a point from the method-signature
(setq x (+ x dx) y (+ y dy))))
In this example, p could have been used to refer to the point itself.
(+ x dx) expands to
(+ (point-x p) dx) etc.
Using %with-slots
(%with-slots (p) (setq x (+ x dx) y (+ y dy))))
(+ x dx) expands to
(+ (get-slot p x) dx)
[text deleted here on syntax of WITH-SLOTS]
%with-slots is identical to with, except that
with-slots expands slot references to access functions and
%with-slots expands slot references to direct accesses
So, I guess the idea is this: You would use %WITH-SLOTS if you really
wanted full access to the slots whether or not they were declared to be
accessible in the DEFCLASS. You would use WITH-SLOTS if you wanted
the system to prevent you from accessing a slot that was not declared
accessible in the DEFCLASS. Another reason to use WITH-SLOTS is to
ensure that the accessor generic function is run -- which might include
some :before or :after methods.
∂18-Sep-86 1306 Owners-CommonLoopsCore↑.pa@Xerox.COM WITH-SLOTS
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 18 Sep 86 13:06:10 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 18 SEP 86 11:02:27 PDT
Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.pa
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
Xerox.COM ; 18 SEP 86 11:02:01 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 107073; Thu
18-Sep-86 13:58:43 EDT
Date: Thu, 18 Sep 86 13:58 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: WITH-SLOTS
To: CommonLoopsCore↑.pa@Xerox.COM
In-Reply-To: <860918-082650-8617@Xerox>
Message-ID: <860918135841.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 18 Sep 86 08:28 PDT
From: Bobrow.pa@Xerox.COM
WITH-SLOTS allows you access slots using a variable name. For example...
The syntax of with-slots is:
(with-slots ({var-name|(var-name var-prefix [class-name]}*) . body)
It's nice to see a concrete specification of something. I have some
syntactic suggestions: I think it would be clearer to use keyword arguments
rather than a mixture of positional arguments and multiple operator names.
I would suggest these three keywords:
:class class-name -- the class, or a super class, of the instance.
:prefix string -- prefixed to the slot names (can be a symbol or a string).
:direct boolean -- t means access slots directly, nil means call the
accessor functions, which might invoke methods.
Thus the syntax would become
(with-slots ({var-name|(var-name &key class prefix direct) . body)
and your examples would become
(defclass point () ((x 0) (y 0)) (:accessors-with-prefix point-))
(defmethod move ((p point) dx dy)
(with-slots (p) ;; p is known to be a point from the method-signature
(setq x (+ x dx) y (+ y dy))))
(with-slots ((p :direct t)) (setq x (+ x dx) y (+ y dy))))
(defmethod make-same-height ((p1 point) (p2 point))
;;; set the y coord of p1 to the y of p2, its reference.
;;; slots of p1 are accessed using the slot names
;;; slots of p2 are accessed using ref-<slot-name>
(with-slots (p1 (p2 :prefix ref-)) (setq y ref-y)))
(defmethod make-horizontal ((l line))
(let ((left (left-point l)) (right (right-point l)))
(with-slots ((left :class point :prefix left-)
(right :class point :prefix right-))
(setq left-y right-y))))
∂18-Sep-86 1306 Owners-CommonLoops.pa@Xerox.COM common loops for franz
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 18 Sep 86 13:06:52 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 18 SEP 86 11:41:26 PDT
Return-Path: <frodo@faraday.ECE.CMU.EDU>
Received: from faraday.ECE.CMU.EDU by Xerox.COM ; 18 SEP 86 11:36:26 PDT
Received: by faraday.ECE.CMU.EDU (4.12/4.7)
id <AA04222 frodo>; Thu, 18 Sep 86 14:24:16 edt;
Date: Thu, 18 Sep 86 14:24:16 edt
From: Ted Kowalski <frodo@faraday.ECE.CMU.EDU>
Message-Id: <8609181824.AA04222@faraday.ECE.CMU.EDU>
To: CommonLoops.pa@Xerox.COM
Subject: common loops for franz
Cc: Gregor.pa@Xerox.COM
the readme.tx file mentions a excl, but I didn't find one in /pub/pcl
does it exist?
thanks
∂18-Sep-86 1724 RPG Proposed Goals (Statement for OOPSLA)
∂18-Sep-86 1100 Owners-commonloopscore↑.pa@Xerox.COM Proposed Goals (Statement for OOPSLA)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 18 Sep 86 10:59:02 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 18 SEP 86 10:02:49 PDT
Return-Path: <RPG@SAIL.STANFORD.EDU>
Redistributed: commonloopscore↑.pa
Received: from SAIL.STANFORD.EDU (SU-AI.ARPA) by Xerox.COM ; 18 SEP 86
10:02:32 PDT
Date: 18 Sep 86 10:01 PDT
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Subject: Proposed Goals (Statement for OOPSLA)
To: commonloopscore↑.pa@Xerox.COM
Message-ID: <860918-100249-8718@Xerox>
Sonya's improvements are generally good. I changed her original
sentence
``We will produce a portable implementation by evolving Portable
Common Loops...''
because it can parse in a funny way if you use a slightly less primary
definition of `evolve' than `to exhibit or produce through evolution.'
The definition is `to emit' as in `to evolve gases.' I parsed it as
it would appear in this sentence:
``Danny Bobrow ate a large plate of refried beans last night, went
back to PARC, and accidentally evolved Portable Common Loops. He
apologized profusely for his bad manners.''
Your rephrasing is better than mine, but it does commit Xerox to doing
the work of updating PCL, which they may elect not to do.
One reason for the phrasing of the pedigree paragraph is to emphasize
that the influence of New Flavors on CommonLoops has been going on for
over a year, and that the proposed standard will be more nearly along
the line of evolution, if you will, of CommonLoops as influenced by
New Flavors than a fresh merging of the two systems off the lines of
either. That is, the proposed standard will not be especially like
the CommonLoops of a year ago, but it will be very much like the
CommonLoops of today, because a movement towards New Flavors has
already taken place.
The reason for wanting to reason this way is to give the community
some sense of continuity over the past year. People will possibly rest
more comfortably if they believe that the ideas have developed over a
year's time rather than over a month's time.
The proposed standard will be what it will be, and its pedigree will
be of interest only to historians, and those historians will be able
to see the family lines accurately.
-rpg-
∂18-Sep-86 1724 RPG DEFCLASS should replace DEFSTRUCT
∂18-Sep-86 1100 Owners-commonloopscore↑.pa@Xerox.COM DEFCLASS should replace DEFSTRUCT
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 18 Sep 86 10:59:08 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 18 SEP 86 10:16:46 PDT
Return-Path: <RPG@SAIL.STANFORD.EDU>
Redistributed: commonloopscore↑.pa
Received: from SAIL.STANFORD.EDU (SU-AI.ARPA) by Xerox.COM ; 18 SEP 86
10:16:32 PDT
Date: 18 Sep 86 10:16 PDT
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Subject: DEFCLASS should replace DEFSTRUCT
To: commonloopscore↑.pa@Xerox.COM
Message-ID: <860918-101646-8740@Xerox>
I bow to those who use mailers that sort mail according to subject:
My message is responsive to the discussion which has gone on under
this subject line, but the contents of my remarks and of the remarks
to which I reply bear no semantic relationship to the subject line.
There indeed was a simplicity in the early CommonLoops proposal, but the
simplicity was the simplicity of a naive proposal. In particular, the
use of Defmethod as a vague replacement for Defun to create a cloud of
functions that are invoked variously misses the goal of a clearly understood
construct. What precisely is the contract between this cloud and the outside
world? How does this cloud relate to Lisp functions? If you can FUNCALL this
cloud, can you affect it by affecting the thing that sits in the symbol-function
cell of a symbol? Simply stated, is the cloud a first-class object, or is it
like the heap?
The `negotiating' group is doing more than negotiating: It is attempting to
bring some design sense into the picture. The early CommonLoops proposal
was more like a slogan than a well-designed system.
-rpg-
∂18-Sep-86 2312 Masinter.pa@Xerox.COM Re: The name of WITH
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 18 Sep 86 23:12:08 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 18 SEP 86 13:25:33 PDT
Date: 18 Sep 86 13:23 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: The name of WITH
In-reply-to: Bobrow.pa's message of 18 Sep 86 08:28 PDT
To: Bobrow.pa@Xerox.COM
cc: CommonLoopsCore↑.pa@Xerox.COM
Message-ID: <860918-132533-897@Xerox>
I think that under a with/with-slots/with-instances that programmers
should be encouraged (required?) to use SETF instead of SETQ to modify
slots.
(defmumble move-to ((p point) new-x new-y)
(with-slots (p)
(setf x new-x)
(setf y new-y)))
even though setq will "do".
I think the "prefix" option was added as a "fix" to the possibility of
conflicting slot names, and that the cure is worse than the disease. If
there's conflict, use the accessor functions instead.
(defmumble move-to-point ((p point) (p2 point))
(with-slots (p)
(setf x (point-x p2))
(setf y (point-y p2))))
∂18-Sep-86 2312 Owners-CommonLoops.pa@Xerox.COM FTP problems.
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 18 Sep 86 23:12:21 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 18 SEP 86 13:44:38 PDT
Return-Path: <ALarson.SoftTech@HI-MULTICS.ARPA>
Received: from HI-MULTICS.ARPA by Xerox.COM ; 18 SEP 86 13:42:04 PDT
Date: Thu, 18 Sep 86 15:31 CDT
From: ALarson@HI-MULTICS.ARPA
Subject: FTP problems.
To: CommonLoops.pa@Xerox.COM
Message-ID: <860918203156.583664@HI-MULTICS.ARPA>
I recently attempted to FTP the PCL software from PARCVAX.xerox.com, and
had much difficulty. Specifically the last 500-2K bytes of most of the
files were not transferred (at least not received). The system
administration people at my site (A large Multics) say no one else has
experienced the same trouble and suggested that I find out if anyone
else trying to get the software was having difficulty. So, did anyone
else have any trouble FTPing the code?
The following is a partial transcript of the FTP session:
The first line below is a DIR, the next two are GETs (of course the first
one worked correctly as predicted by Murphy).
Aaron.
----------------------------------------
user←ftp: -rw-r--r-- 1 270 41 10366 May 30 11:01 defsys.l
user←ftp: 150 Opening data connection for defsys.l (10.1.0.94,62250) (10366 bytes).
226 Transfer complete.
Total elapsed time: 27.6 seconds.
10366 bytes transferred in 24.4 seconds (3343 bits/sec).
user←ftp:
user←ftp: 150 Opening data connection for defsys.l (10.1.0.94,43178) (10366 bytes).
226 Transfer complete.
Total elapsed time: 30.7 seconds.
10224 bytes transferred in 25.5 seconds (3150 bits/sec).
user←ftp:
∂18-Sep-86 2312 Masinter.pa@Xerox.COM Re: DEFCLASS should replace DEFSTRUCT
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 18 Sep 86 23:12:34 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 18 SEP 86 13:48:55 PDT
Date: 18 Sep 86 13:47 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: DEFCLASS should replace DEFSTRUCT
In-reply-to: Dick Gabriel <RPG@SAIL.STANFORD.EDU>'s message of 18 Sep 86
10:16 PDT
To: RPG@SAIL.STANFORD.EDU
cc: commonloopscore↑.pa@Xerox.COM
Message-ID: <860918-134855-900@Xerox>
Having missed the early discussions of what ambiguity lies in the
original specification, I am forced to repeat the questions and hope
that you will have the patience to repeat the replies. If it is any
consolation, I think you will have to repeat this with others who might
have liked the spec, and suggest, if you have not done so, save your
replies.
To address your particular concerns:
"In particular, the use of Defmethod as a vague replacement for Defun to
create a cloud of
functions that are invoked variously misses the goal of a clearly
understood construct. What precisely is the contract between this cloud
and the outside world? "
What precisely is the contract between an ordinary function and the
outside world?
The specification of the behavior of a set of methods is no less defined
than the specification of what functions, macros and special forms do in
Common Lisp.
"How does this cloud relate to Lisp functions?"
It is different from any lisp function.
"If you can FUNCALL this cloud, can you affect it by affecting the thing
that sits in the symbol-function cell of a symbol? "
You cannot FUNCALL a cloud. You can FUNCALL a symbol and a function
object. A set of methods is neither. Perhaps you are asking the more
precise question:
"After (defmethod move ((x point) dx dy) ...), what does
(symbol-function 'move) return?"
I would answer that the answer belongs in the standard as much as the
question
"After (defmacro mood (x dx dy) ...), what does (symbol-function 'mood)
return?"
on which Common Lisp the Language is silent.
I think that your characterization of the early CommonLoops proposal as
"more like a slogan than a well-designed system." is incorrect, and even
more perjorative than the characterization of Common Lisp as "more like
a treaty than a specification."
∂18-Sep-86 2313 Owners-CommonLoops.pa@Xerox.COM Re: common loops for franz
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 18 Sep 86 23:13:29 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 18 SEP 86 15:35:09 PDT
Return-Path: <dcmartin@ingres.Berkeley.EDU>
Received: from ingres.Berkeley.EDU ([128.32.156.105]) by Xerox.COM ; 18
SEP 86 15:32:59 PDT
Received: by ingres.Berkeley.EDU (5.53/1.2)
id AA28636; Thu, 18 Sep 86 14:38:01 PDT
Message-Id: <8609182138.AA28636@ingres.Berkeley.EDU>
From: "David C. Martin" <dcmartin@ingres.Berkeley.EDU>
Office: 440 Evans - x2-9585
Home: 2441 Haste St #37, Berkeley, CA 94704 - (415) 843-6470
Fortran: is not backward, NARTROF is backwards.
To: Ted Kowalski <frodo@faraday.ece.cmu.edu>
Cc: CommonLoops.pa@Xerox.COM, Gregor.pa@Xerox.COM
Precedence: priority-mail
In-Reply-To: Your message of Thu, 18 Sep 86 14:24:16 edt
Subject: Re: common loops for franz
Date: 18 Sep 86 14:37:58 PDT (Thu)
Sender: dcmartin@ingres.Berkeley.EDU
Yeah, there should be... I am running it w/ Franz ExCl and I last updated
on 8/28 from parcvax. If you would like, I can make it publically ftp'able
from my VAX. We have also added the make-specializable feature to the
Franz implementation.
dcm
∂18-Sep-86 2313 Masinter.pa@Xerox.COM Re: FTP problems.
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 18 Sep 86 23:13:12 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 18 SEP 86 15:00:48 PDT
Date: 18 Sep 86 14:56 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: FTP problems.
In-reply-to: ALarson@HI-MULTICS.ARPA's message of Thu, 18 Sep 86 15:31
CDT
To: ALarson@HI-MULTICS.ARPA
cc: CommonLoops.pa@Xerox.COM, VaxcSystem↑.pa@Xerox.COM
Message-ID: <860918-150048-907@Xerox>
parcvax has been having hiccups with a new version of Unix. I'm not sure
they've been resolved yet, will keep you posted.
∂18-Sep-86 2313 Bobrow.pa@Xerox.COM Re: Proposed Goals (Statement for OOPSLA)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 18 Sep 86 23:12:56 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 18 SEP 86 14:11:59 PDT
Date: 18 Sep 86 14:13 PDT
From: Bobrow.pa@Xerox.COM
Subject: Re: Proposed Goals (Statement for OOPSLA)
To: CommonLoopsCore↑.pa@Xerox.COM
Message-ID: <860918-141159-904@Xerox>
In reading over these messages, I realized that what we were doing was
not describing technical goals and history, but setting up marketing
positions for corporations. I (and Gregor) are not in any position to
negotiate statements that have that kind of implication, and this
discussion is not appropriate for this list. Instead, let's continue
discussions of the important technical issues we need to resolve.
-- danny
∂19-Sep-86 0806 Owners-CommonLoopsCore↑.PA@Xerox.COM Re: Summary of features we all agree on
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 19 Sep 86 08:06:27 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 19 SEP 86 08:04:35 PDT
Return-Path: <skeene@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.PA
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
Xerox.COM ; 19 SEP 86 08:03:52 PDT
Received: from JUNCO.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 107881; Fri
19-Sep-86 10:57:38 EDT
Date: Fri, 19 Sep 86 10:55 EDT
From: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Summary of features we all agree on
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CommonLoopsCore↑.PA@Xerox.COM
In-Reply-To: <860910003916.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <860919105557.2.SKEENE@JUNCO.SCRC.Symbolics.COM>
Line-fold: No
Date: Wed, 10 Sep 86 00:39 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Date: 5 Sep 86 18:49 PDT
From: Bobrow.pa@Xerox.COM
class-name is a non-null symbol that names the class being
defined. If a class is already defined with this name, this
definition replaces the old definition. The default
meta-class ensures that when the definition of a class
changes, each existing instance of the class is updated to the
new format the next time it is accessed.
Each slot-spec is one of:
slot-name a non-null symbol.
(slot-name initial-value-form)
(slot-name slot-option...)
Each slot-option is an option name followed by its value.
The defined slot-options and their arguments are:
= initial-value-form
This an alternate way for providing a default
initial value form.
By the way I'm not wedded to the name "=". I couldn't think of
a clearer name when I tried for a few minutes, but perhaps
someone else can.
The name "=" seems inappropriate here.
How about :initial-value? Other possibilities: :default-value,
:default-initial-value, :initial-contents.
:accessor generic-function-name
Specifies that a function named generic-function-name
be automatically generated, to read the value of this
slot. SETF may be used with generic-function name to
write the value of the slot.
OK. If generic-function-name is NIL then this is a NOOP.
Specified so programs can generate these.
:reader generic-function-name
Specifies that a function named generic-function-name
be automatically generated, to read the value of this
slot.
We have called this :read-accessor.
I think users would find the distinction between :read-accessor
and :accessor confusing. Perhaps we need some more opinions
here, it's a difficult judgement.
The important distinction that these names have to imply is that one
generic function can read and write, while the other can only read.
The name :read-accessor is confusing. It implies that the generic
function is capable of both reading and accessing.
The names :accessor and :read-accessor do not go together well. If
we are going to use :reader-accessor, the appropriate companion option
should be named :read-and-write-accessor. That way the user
understands that :read-and-write-accessor does more than :read-accessor.
I prefer the names :accessor and :reader because they really describe
what the generic function can do. The one generated by :ACCESSOR has
the capability of ACCESSING (both reading and being used with SETF).
The one generated by :READER has the capability of READING.
We specify that if this is
given, then SETF may NOT be used with this accessor. If
generic-function-name is NIL then this is a NOOP.
Agreed.
∂19-Sep-86 0944 Bobrow.pa@Xerox.COM Re: Summary of features we all agree on
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 19 Sep 86 09:44:08 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 19 SEP 86 09:37:30 PDT
Date: 19 Sep 86 09:37 PDT
Sender: Bobrow.pa@Xerox.COM
Subject: Re: Summary of features we all agree on
In-reply-to: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Fri, 19 Sep 86 10:55 EDT
To: skeene@STONY-BROOK.SCRC.Symbolics.COM
cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, CommonLoopsCore↑.PA@Xerox.COM
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Message-ID: <860919-093730-1229@Xerox>
The important distinction that these names have to imply is
that one generic function can read and write, while the other can
only read.
The name :read-accessor is confusing. It implies that the
generic function is capable of both reading and accessing.
The names :accessor and :read-accessor do not go together well.
If we are going to use :reader-accessor, the appropriate companion
option should be named :read-and-write-accessor. That way the
user understands that :read-and-write-accessor does more than
:read-accessor.
I prefer the names :accessor and :reader because they really
describe what the generic function can do. The one generated by
:ACCESSOR has the capability of ACCESSING (both reading and being
used with SETF). The one generated by :READER has the capability of
READING.
I like this choice of names, :accessor and :reader.
-- danny
∂19-Sep-86 1132 Owners-CommonLoopsCore↑.PA@Xerox.COM Re: Summary of features we all agree on
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 19 Sep 86 11:31:55 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 19 SEP 86 10:42:24 PDT
Return-Path: <skeene@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.PA
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
Xerox.COM ; 19 SEP 86 10:42:02 PDT
Received: from JUNCO.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 108123; Fri
19-Sep-86 13:40:40 EDT
Date: Fri, 19 Sep 86 13:38 EDT
From: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Summary of features we all agree on
To: Moon@STONY-BROOK.SCRC.Symbolics.COM, bobrow.pa@Xerox.COM
cc: CommonLoopsCore↑.PA@Xerox.COM
In-Reply-To: <860910003916.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <860919133856.4.SKEENE@JUNCO.SCRC.Symbolics.COM>
Line-fold: No
Date: Wed, 10 Sep 86 00:39 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Date: 5 Sep 86 18:49 PDT
From: Bobrow.pa@Xerox.COM
This is from the section on DEFCLASS slot-options.
:allocation
:allocation can have values
:instance (allocated in the instance),
:class (storage allocated in the class and shared by all
instances),
:dynamic (storage allocated in the instance on first use
(like Flavors Proplist mixin)
:none expect accessor methods for this to be defined for
this slot in this class
We need to discuss which of these allocation options belong in
the standard. Maybe only a subset of them.
This is the last I've heard (read) of :allocation. Maybe it's time to
start discussing the :allocation options again. I've elaborated on
Danny's write-up above with some information from the CommonLoops paper,
and added one thing. For :dynamic, I assume that if you initialize
the slot with a keyword argument to MAKE-INSTANCE, the slot gets
allocated right then. True?
Also, would you clarify what you meant by:
:none expect accessor methods for this to be defined for
this slot in this class
---------------------------------------------------------------------
:allocation keyword
Specifies where storage is allocated for this slot. The keyword can
be one of these:
:instance Storage is allocated in the instance itself; each
instance has its separate value for this slot. This
is the default.
:class Storage is allocated in the class. Thus a single
value for this slot is shared by all instances.
:dynamic Storage is allocated in the instance at the time of
the first use of the slot. If the slot is initialized
with a keyword argument to MAKE-INSTANCE, the slot is
allocated then. If the first access is a read, then
storage is allocated and the default value declared
in the DEFCLASS, if any, is stored in the slot and
returned. If the first access is a SETF, then storage
is allocated and the value is stored in the slot and
returned. This option allows infrequently-used slots
to take storage only when necessary.
:none No storage is to be allocated; the slot should not
exist in instances of this class. This is used to
override inheritance of slots defined by a
super-class.
∂19-Sep-86 1132 Kahn.pa@Xerox.COM Short names like MAKE
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 19 Sep 86 11:32:02 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 19 SEP 86 10:45:24 PDT
Date: 19 Sep 86 10:37 PDT
Sender: Kahn.pa@Xerox.COM
Subject: Short names like MAKE
To: CommonLoopsCore↑.pa@Xerox.COM
cc: Kahn.pa@Xerox.COM
From: Ken Kahn <Kahn.pa@Xerox.COM>
Message-ID: <860919-104524-1315@Xerox>
I've hesitated to bring this up since it seems that everyone is happy
with the change from MAKE to MAKE-INSTANCE. I'm not.
I think short names are appropriate when something is used frequently
enough. I'm glad LET isn't called LET-VARIABLES, CONS isn't called
MAKE-CONS etc. My expectation is that all user defined data structures
will be created by MAKE(-INSTANCE) and that programs frequently do
create structures. To put it more extremely than I really believe --
The only things that programs will make will be made by MAKE or by
existing primitive type creation functions (CONS, MAKE-ARRAY...)
I feel less strongly about WITH vs WITH-INSTANCE since I don't really
know how often people will be using it explictly.(Btw, I like Moon's
WITH keyword syntax for dealing with prefix, class etc. though I also
share Larry's concern that the cases where they will be used are rare
enough that the added complexity isn't worth it.)
----- ken
∂20-Sep-86 1132 Owners-commonloopscore↑.pa@Xerox.COM Short Names
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 20 Sep 86 11:31:59 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 20 SEP 86 10:36:38 PDT
Return-Path: <RPG@SAIL.STANFORD.EDU>
Redistributed: commonloopscore↑.pa
Received: from SAIL.STANFORD.EDU (SU-AI.ARPA) by Xerox.COM ; 20 SEP 86
10:36:27 PDT
Date: 20 Sep 86 10:36 PDT
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Subject: Short Names
To: commonloopscore↑.pa@Xerox.COM
Message-ID: <860920-103638-2050@Xerox>
It is tempting to want to use short names for things that are imagined to
be used frequently. People designing an object-oriented programming
language feel that the primitives they define will be the ones frequently
used. Recall that in the overall age of Lisp, CommonLoops has hardly
any history. Moreover, because the designer of it feels that his primitives
are the right ones, perhaps a second-generation CommonLoops hacker
will feel that some different primitives are right.
In Common Lisp we decided to not use up many of the `good' names
or characters so that users could have them. Exceptions are time-honored
Lisp names, such as LET and CONS.
If you choose a long name for MAKE-INSTANCE, then the user can
macro-ify it to a short name. If you choose a short, nice name
like MAKE, no one else can use it. That is, the long name is
the safe choice.
Also, do you suppose that your choice of the meaning of an
English word like MAKE for a technical operation is better than
what a real programmer would want to choose as the meaning?
I strongly object to using names that are likely to be of use to
programmers to name operations that are meaningful in his application.
-rpg-
∂21-Sep-86 1230 masinter.PA@Xerox.COM mutable vs immutable generic functions
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 21 Sep 86 12:30:09 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 SEP 86 12:27:06 PDT
From: masinter.PA@Xerox.COM
Date: 21 Sep 86 12:26:49 PDT
Subject: mutable vs immutable generic functions
To: commonloopscore↑.pa@Xerox.COM, pavel.PA@Xerox.COM,
nuyens.PA@Xerox.COM, sybalsky.PA@Xerox.COM
Message-ID: <860921-122706-1235@Xerox>
(This note came out of a design review meeting with some of the Common
Lisp implementors here. )
This is very condensed form of the arguments:
The question is: are Generic Functions mutable or immutable objects?
Example:
(defmethod foo ((a widget)) .1.)
(setq foofn #'foo)
(defmethod foo ((a warble)) .2.)
(funcall foofn (make-warble) ...)
Mutable:
defmethod, add-method, remove-method, etc. destructively modify the
generic function to include the new method. In the example, the funcall
will get definition .2..
Immutable:
Generic functions are still objects that can be passed around, sent to
FUNCALL, etc. However, they are immutable. add-method, remove-method
merely return a {it new} generic function with the specified method
added or removed. In the example, the funcall will get a generic
function which does *not* see the defmethod.
defmethod merely replaces symbol-function with a new generic function.
Unspecified:
The standard doesn't say. Implementations are free to choose. It is an
error to rely upon what happens.
Pro & Cons:
mutable vs immutable:
mutable better than immutable:
Mutable is a powerful feature. It is consistent with the current
implementation of PCL. (This is what's written in the documentation that
I have.) Mutable allows more efficient method-definition than immutable.
Immutable is better than mutable:
Mutable is too powerful a feature. It allows programs to do things they
shouldn't be able to do). Mutable is inconsistent with the use of
functions elsewhere in Common Lisp. (A program could, when handed a
function, remove all of its methods and insert a "default
implementation" of its own choosing).
Unspecified vs specified:
spec it: Programs that depend on one behavior vs the other will be
difficult to port if left unspecified.
don't spec it: Many programs won't care, and leaving it unspecified will
allow greater implementation freedom. If we can't agree, we will have to
leave it unspecified.
∂21-Sep-86 1355 Bobrow.pa@Xerox.COM Syntax of DEFCLASS
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 21 Sep 86 13:55:11 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 SEP 86 13:51:48 PDT
Date: 21 Sep 86 13:51 PDT
Sender: Bobrow.pa@Xerox.COM
Subject: Syntax of DEFCLASS
To: CommonLoopsCore↑.pa@Xerox.COM
cc: Bobrow.pa@Xerox.COM
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Message-ID: <860921-135148-1298@Xerox>
In an internal design review at Xerox of the current state of the
specification, strong arguments were presented why defclass should have
a syntax parallel to that of defstruct. These were:
1) Learnability -- Currently people know that syntax. Simple variations
ae easier to learn than extensive ones.
2) Documentation -- Current documentation of defstruct could be used in
large part to document defclass. This makes the book stay smaller. It
makes all books written about Common Lisp have to say less.
3) Elimination of defstruct from the language -- If the syntax is
similar, and the transformation from defstruct to defclass forms is
straightforward, it will be easier to argue for the removal of
defstruct. (Creation of structures and use of :type might be replaced
by use of the :metaclass option.)
The major problem with using defstruct synatx for defclass seems to be
figuring out how to avoid having two conflicting sets of options
depending on the :metaclass.
In particular, the current :accessors-with-prefix defclass option is
different than the :conc-name option.
Other, less significant options which cause problems are
:initable-slots, :initialize-only vs. :read-only and :init-keywords.
-- danny
∂21-Sep-86 1433 Owners-CommonLoopsCore↑.PA@Xerox.COM mutable vs immutable generic functions
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 21 Sep 86 14:33:07 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 21 SEP 86 14:32:30 PDT
Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.PA
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
Xerox.COM ; 21 SEP 86 14:32:05 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 109234; Sun
21-Sep-86 17:30:25 EDT
Date: Sun, 21 Sep 86 17:29 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: mutable vs immutable generic functions
To: CommonLoopsCore↑.PA@Xerox.COM
cc: masinter.PA@Xerox.COM, pavel.PA@Xerox.COM, nuyens.PA@Xerox.COM,
sybalsky.PA@Xerox.COM
In-Reply-To: <860921-122706-1235@Xerox>
Message-ID: <860921172940.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 21 Sep 86 12:26:49 PDT
From: masinter.PA@Xerox.COM
The question is: are Generic Functions mutable or immutable objects?
Example:
(defmethod foo ((a widget)) .1.)
(setq foofn #'foo)
(defmethod foo ((a warble)) .2.)
(funcall foofn (make-warble) ...)
Mutable:
defmethod, add-method, remove-method, etc. destructively modify the
generic function to include the new method. In the example, the funcall
will get definition .2..
Immutable:
Generic functions are still objects that can be passed around, sent to
FUNCALL, etc. However, they are immutable. add-method, remove-method
merely return a {it new} generic function with the specified method
added or removed. In the example, the funcall will get a generic
function which does *not* see the defmethod.
defmethod merely replaces symbol-function with a new generic function.
Unspecified:
The standard doesn't say. Implementations are free to choose. It is an
error to rely upon what happens.
Pro & Cons:
mutable vs immutable:
mutable better than immutable:
Mutable is a powerful feature. It is consistent with the current
implementation of PCL. (This is what's written in the documentation that
I have.) Mutable allows more efficient method-definition than immutable.
Immutable is better than mutable:
Mutable is too powerful a feature. It allows programs to do things they
shouldn't be able to do). Mutable is inconsistent with the use of
functions elsewhere in Common Lisp. (A program could, when handed a
function, remove all of its methods and insert a "default
implementation" of its own choosing).
Unspecified vs specified:
spec it: Programs that depend on one behavior vs the other will be
difficult to port if left unspecified.
don't spec it: Many programs won't care, and leaving it unspecified will
allow greater implementation freedom. If we can't agree, we will have to
leave it unspecified.
Your arguments make sense to me, and I firmly believe that it should be
unspecified. Here's why:
In New Flavors the interaction between doing #'foo and adding or
removing a method of foo varies depending on factors that the user might
not be able to predict easily. This is because there are multiple
implementations of what PCL calls discriminating functions, and
depending on which implementation Flavors happens to choose the result
of #'foo might capture some or all of the current set of methods or
might be independent of the current set of methods. I imagine that on
stock-hardware this implementation freedom would be even more important,
if high performance was a goal. In your terminology, generic functions
in New Flavors are sometimes mutable, sometimes immutable, and sometimes
partially mutable.
This has not bothered any programmers, as far as I know, in the 9 or 10
months that New Flavors has been in use. This shouldn't surprise us,
since ordinary functions behave similarly. Consider these examples:
[1] (defun foo (...)
...
(foo-1...))
(defun foo-1 (...)
...)
[2] (defun foo (...)
(flet ((foo-1 (...) ...))
...
(foo-1...)))
Suppose someone does #'foo and saves it away, and then a second someone
redefines foo-1, an internal function of foo whose existence is not known
to the first someone. In example 1, the behavior of the saved-away foo
changes, in example 2 it stays the same, yet as far as the contract of
the function foo is concerned these two ways of implementing its
internal function are equivalent.
Depending on one's taste, one could say this shows that Common Lisp does
not have a well-defined semantics, or one could say that this is just an
example of the way that, in Lisp, copying the value of a variable
doesn't copy the object, just the reference to the object. Either way,
I think it makes sense for generic functions to have the same freedom of
behavior when their internal subroutines are changed that ordinary
functions enjoy.
∂21-Sep-86 1529 Owners-CommonLoopsCore↑.pa@Xerox.COM Syntax of DEFCLASS
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 21 Sep 86 15:29:14 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 21 SEP 86 15:22:58 PDT
Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.pa
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
Xerox.COM ; 21 SEP 86 15:22:33 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 109241; Sun
21-Sep-86 18:21:05 EDT
Date: Sun, 21 Sep 86 18:20 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Syntax of DEFCLASS
To: CommonLoopsCore↑.pa@Xerox.COM
In-Reply-To: <860921-135148-1298@Xerox>
Message-ID: <860921182022.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 21 Sep 86 13:51 PDT
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
In an internal design review at Xerox of the current state of the
specification, strong arguments were presented why defclass should have
a syntax parallel to that of defstruct. These were:
I thought we had been through this already. I'll see if I can reconstruct
the arguments that lead to the decision not to use the defstruct syntax.
1) Learnability -- Currently people know that syntax. Simple variations
ae easier to learn than extensive ones.
This is true, but on the other hand the syntax of defstruct is not
consistent with the syntax of anything else. In any case this is hardly
likely to be the part that newcomers to object-oriented programming find
the most difficult to learn.
2) Documentation -- Current documentation of defstruct could be used in
large part to document defclass. This makes the book stay smaller. It
makes all books written about Common Lisp have to say less.
This is true, but the percentage decrease in the description of
object-oriented programming would be quite small.
3) Elimination of defstruct from the language -- If the syntax is
similar, and the transformation from defstruct to defclass forms is
straightforward, it will be easier to argue for the removal of
defstruct. (Creation of structures and use of :type might be replaced
by use of the :metaclass option.)
This is true, but not compelling. Defstruct could be removed from the
language regardless of whether the syntax is similar, as long as a given
defstruct form can be mechanically translated into an equivalent defclass
form.
The major problem with using defstruct synatx for defclass seems to be
figuring out how to avoid having two conflicting sets of options
depending on the :metaclass.
In particular, the current :accessors-with-prefix defclass option is
different than the :conc-name option.
Other, less significant options which cause problems are
:initable-slots, :initialize-only vs. :read-only and :init-keywords.
I don't think these are the main problems at all. The real problem with
defstruct is that it was designed nine years ago, is not consistent with
current ideas of easy-to-understand syntax for defining forms, and is
a gross kludge. Rather than perpetuate this wart on the language, we
ought to be replacing it with something better. Requiring compatibility
with defstruct is requiring compatibility with the mistakes of the past,
and in my opinion would seriously impair the understandability and
usability of the object-oriented programming facility for only small
gains. All of the arguments above are true, but I think they are much
too weak to outweigh the problems of defstruct. Here are some specifics:
The original syntax of defstruct didn't allow for options, so they had
to be added by a kludge -- replacing the name with a list of the name
and options. The original syntax of defstruct didn't allow for
documentation, so it had to be added by another kludge -- using a string
instead of a slot name. Slot-options had to be added by yet a third
kludge, which requires that an initialization form be specified whether
or not it is desired in order to specify slot-options. The format of
slot-options is not consistent with the format of regular options
(admittedly the currently proposed DEFCLASS has the same problem, and it
appears to be difficult to fix). The format of the :INCLUDE option does
not admit straightforward extension to multiple superclasses; one kludge
or another is required to get around this.
Defstruct contains violations of abstraction or modularity; it has no
concept of a separation between the implementation of a structure (or
class) and clients of that structure or class. For example, all slots
can be initialized to arbitrary values when constructing a structure;
this ought to be under the control of the implementation of the
structure. Similarly, the ability of the implementation of a structure
to modify a slot is not separated from the ability of the clients to do
so.
The default values for the :CONC-NAME, :CONSTRUCTOR, :COPIER, and
:PREDICATE options are inappropriate. (Perhaps not everyone agrees that
all of these are inappropriate, but the existence of controversy is
sufficient reason by itself to reconsider these defaults.) If the
object-oriented facility is an extension of DEFSTRUCT, it would be
forced to make the same inappropriate choices for the sake of
compatibility.
Given all of these problems, a clean break with the past is a better
choice than trying to maintain compatibility with a kludge. Of course
defstruct cannot be removed immediately, because one does not make
sudden incompatible changes to a language that thousands of people are
using, but the long-term plan should be to phase out defstruct once
a replacement has been accepted as a standard.
∂21-Sep-86 1537 MASINTER.PA@Xerox.COM (change-class x y) => (setf (class-of x) y)?
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 21 Sep 86 15:37:30 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 SEP 86 15:35:27 PDT
From: MASINTER.PA@Xerox.COM
Date: 21 Sep 86 15:34:29 PDT
Subject: (change-class x y) => (setf (class-of x) y)?
To: commonloopscore↑.PA@Xerox.COM
cc: nuyens.PA@Xerox.COM, sybalsky.PA@Xerox.COM, pavel.PA@Xerox.COM
Message-ID: <860921-153527-1339@Xerox>
There doesn't seem to be any apparent reason to make change-class a
separate "thing", rather than a notation that class-of is setf-able for
some kinds of objects.
Opinions?
∂21-Sep-86 1540 Bobrow.pa@Xerox.COM Generic Function Objects
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 21 Sep 86 15:39:59 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 SEP 86 15:39:30 PDT
Date: 21 Sep 86 15:39 PDT
Sender: Bobrow.pa@Xerox.COM
Subject: Generic Function Objects
To: CommonLoopsCore↑.pa@Xerox.COM
cc: Bobrow.pa@Xerox.COM
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
Message-ID: <860921-153930-1345@Xerox>
In the existing CommonLoops papers and code, there is an object called
the discriminator and piece of code called the discriminating function.
The discriminating function was stored inside the discriminator, and
when the discriminator was "named", was also stored in the
symbol-function cell of the symbol which named the discriminator. The
discriminating-function was the thing you funcalled, the discriminator
was the thing that you passed to add-method.
A potentially better design combines the discriminator and the
discriminating function into a single, closure-like, object called the
generic function. The generic function is funcallable; funcalling it
causes method lookup to happen. Accessors which used to work on the
discriminator work directly on the generic function. In particular,
generic-function-methods returns a list of all the methods defined on a
generic function.
Generic functions are mutable, and are side-effected by add-method and
remove-method. An alternative proposal makes them immutable, add-method
and remove-method return new generic-functions, see Masinter's message
of 21-Sep-86 12:26:49 PDT.
We spent a fair amount of time discussing the implementation
implications of this. We believe that this does not cause serious
implementation problems. At least the mutable case can even be
implemented fairly efficiently in PCL.
This new scheme has not yet been discussed on this list though. This
message is intended to spark that discussion.
-- danny, Gregor
∂21-Sep-86 1553 MASINTER.PA@Xerox.COM make vs make-instance
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 21 Sep 86 15:53:15 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 SEP 86 15:51:01 PDT
From: MASINTER.PA@Xerox.COM
Date: 21 Sep 86 15:50:46 PDT
Subject: make vs make-instance
To: commonLoopsCore↑.PA@Xerox.COM
Message-ID: <860921-155101-1347@Xerox>
The CommonLoops paper used only two short names, viz "make" and "with".
"make" was chosen, not so much because it is frequently typed and thus
needs to be short, but rather in conformance with the Common Lisp style
in defstruct, namely that
(make-ship :a 3 :b 17)
seemed like a simple step away from
(make 'ship :a 3 :b 17)
and is further away from
(make-instance 'ship :a 3 :b 17).
If it is any help, make-instance is also incompatible with having a
structure named "instance", which seems as likely to me at the moment as
the user having a function or macro named "make".
∂21-Sep-86 1615 Bobrow.pa@Xerox.COM Re: (change-class x y) => (setf (class-of x) y)?
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 21 Sep 86 16:08:24 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 SEP 86 16:05:03 PDT
Date: 21 Sep 86 16:03 PDT
Sender: Bobrow.pa@Xerox.COM
Subject: Re: (change-class x y) => (setf (class-of x) y)?
In-reply-to: MASINTER.PA's message of 21-Sep-86 15:34:29 PDT
To: MASINTER.PA@Xerox.COM
cc: commonloopscore↑.PA@Xerox.COM, nuyens.PA@Xerox.COM,
sybalsky.PA@Xerox.COM, pavel.PA@Xerox.COM
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Message-ID: <860921-160503-1357@Xerox>
(change-class x y) => (setf (class-of x) y)?
There doesn't seem to be any apparent reason to make
change-class a separate "thing", rather than a notation that
class-of is setf-able for some kinds of objects.
change-class is a sufficiently serious operation that having a separate
name is important. It does significantly more than simply set a field,
so (setf (class-of x) y) would be misleading to a user.
-- danny
∂21-Sep-86 1638 Kahn.pa@Xerox.COM Re: Short Names
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 21 Sep 86 16:38:52 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 SEP 86 16:34:16 PDT
Date: 21 Sep 86 16:34 PDT
Sender: Kahn.pa@Xerox.COM
Subject: Re: Short Names
In-reply-to: Dick Gabriel <RPG@SAIL.STANFORD.EDU>'s message of 20 Sep 86
10:36 PDT
To: RPG@SAIL.STANFORD.EDU
cc: commonloopscore↑.pa@Xerox.COM
From: Ken Kahn <Kahn.pa@Xerox.COM>
Message-ID: <860921-163416-1364@Xerox>
In Common Lisp we decided to not use up many of the `good' names
or characters so that users could have them. Exceptions are
time-honored Lisp names, such as LET and CONS.
Skimming the index of the Silver book reveals the following short names
which to my knowledge were not "time-honored Lisp names":
bit, block, byte, close, character, complex, count, describe, elt,
every, export, find, import, keyword, loop, merge, ...
----- ken
∂21-Sep-86 1717 Kahn.pa@Xerox.COM Re: (change-class x y) => (setf (class-of x) y)?
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 21 Sep 86 17:17:03 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 SEP 86 17:15:50 PDT
Date: 21 Sep 86 17:15 PDT
Sender: Kahn.pa@Xerox.COM
Subject: Re: (change-class x y) => (setf (class-of x) y)?
In-reply-to: Danny Bobrow <Bobrow.pa>'s message of 21 Sep 86 16:03 PDT
To: Bobrow.pa@Xerox.COM
cc: MASINTER.PA@Xerox.COM, commonloopscore↑.PA@Xerox.COM,
nuyens.PA@Xerox.COM, sybalsky.PA@Xerox.COM, pavel.PA@Xerox.COM
From: Ken Kahn <Kahn.pa@Xerox.COM>
Message-ID: <860921-171550-1381@Xerox>
I like Larry's suggestion for the same reasons that most people like
SETF -- fewer names to deal with.
change-class is a sufficiently serious operation that having a
separate name is important. It does significantly more than simply
set a field, so (setf (class-of x) y) would be misleading to a
user.
Its true that the implementation would do "significantly more than
simply set a field" but I fail to see why that misleads the user.
Consider in Common Lisp (SETF (MACRO-FUNCTION ...) ...) which in some
implementations causes a macro expansion cache to become invalidated
causing some hash tables to be cleared. How is the user "mislead" here?
Do you mean that in the two cases the user is likely to have a mistaken
performance model by using SETF? But (SETF (GET-SLOT ...) ..)
may cause arbitrary computation too.
----- ken
∂21-Sep-86 1725 Kahn.pa@Xerox.COM Re: default optional arguments to a generic function
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 21 Sep 86 17:25:08 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 SEP 86 17:23:57 PDT
Date: 21 Sep 86 17:23 PDT
Sender: Kahn.pa@Xerox.COM
Subject: Re: default optional arguments to a generic function
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Wed, 17 Sep 86 16:15 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CommonLoopsCore↑.pa@Xerox.COM
From: Ken Kahn <Kahn.pa@Xerox.COM>
Message-ID: <860921-172357-1384@Xerox>
(defun draw (thing &optional (place *draw-window*
place-supplied-p))
"Draw thing on place."
(draw-internal thing place place-supplied-p))
(defmethod draw-internal ((thing line) (place raster-display)
place-supplied-p) ...)
(defmethod draw-internal ((thing line) (place vector-display)
place-supplied-p) ...)
Flavors provides the feature that you don't have to make
up the auxiliary name draw-internal, which is confusing because
the externally visible interface is named draw but you put methods
on draw-internal. You do this by (translating out of the present
Flavors syntax, which is too biased against multimethods):
(defgeneric draw (thing &optional (place *draw-window*
place-supplied-p))
"Draw thing on place."
(:method-arguments thing place place-supplied-p)
(:function
(funcall (generic draw) thing place place-supplied-p)))
(defmethod draw ((thing line) (place raster-display)
place-supplied-p) ...)
(defmethod draw ((thing line) (place vector-display)
place-supplied-p) ...)
I liked your proposal until I started to imagine myself writing DRAW
methods and having to keep in my head that someone can call DRAW with 1
or 2 arguments but my methods have 3 required arguments. I find this
less confusing than the alternative of using DRAW-INTERNAL where "the
externally visible interface is named draw but you put methods on
draw-internal".
----- ken
∂21-Sep-86 1812 Bobrow.pa@Xerox.COM default optional arguments to a generic function
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 21 Sep 86 18:12:35 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 SEP 86 18:06:17 PDT
Date: 21 Sep 86 18:06 PDT
Sender: Bobrow.pa@Xerox.COM
Subject: default optional arguments to a generic function
To: CommonLoopsCore↑.pa@Xerox.COM
cc: Bobrow.pa@Xerox.COM
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Message-ID: <860921-180617-1396@Xerox>
The following principles seem to be ones we have agreed to with respect
to generic functions and methods.
1) Methods should be able to take any Common Lisp lambda-list. In
particular the default defmethod must be able to look like a defun.
2) defgeneric should be optional, unless special options are used, such
as :generic-function-class.
3) The contract of the generic function should be true for all methods,
and that contract should be computable from a defmethod form.
This seems to lead to two competing proposals (Gregor says I am
oversimplifying)
Proposal a) The generic function specifies the full argument list, and
all methods must have congruent argument lists. This leads to the
problem of defining congruence (Moon proposed some rules, but as
Masinter pointed out, they had a problem with renaming of variables used
in default value forms). It also leads to redundancy in the methods --
making it difficult to change a default value form in a single place.
However, Gregor favors this scheme as later extendible by removing
restrictions. He would allow methods to take extra keywrod args if
&allow-other-keys appears in the defgeneric.
Proposal b) The generic function specifies only the required arguments,
and methods discriminate only on those arguments. However, methods can
have arbitrary argument list beyond the required arguments. From any
method, the generic contract can be computed. All methods must have the
same number of min-args.
This allows cases 1a) and 1b)
Case 1a. "draw-line"
draw-line takes an optional, the width of the line in
device dependent units. Because they are device dependent
units, each individual method would like to default this
argument on its own.
(defmethod draw-line ((dev printer) p1 p2
&optional (width 7)) ...)
(defmethod draw-line ((dev window) p1 p2
&optional (width 1)) ...)
Case 1b.
Within case 1, some methods may want to take an extra
argument. Also see case 3 which is similar.
(defmethod draw-line ((d gray-display) p1 p2
&optional (width 3)
(gray *gray1*))
..)
Date: Wed, 17 Sep 86 16:15 EDT
From: David A. Moon
The problem here is that the generic function doesn't have a
consistent contract. The meaning, or even the existence, of one
argument depends on the class of another argument. I don't see how
a caller of draw-line could operate without knowing the exact
method that was going to be called. From experience I know it's
possible to have all sorts of arguments about whether this is good
or bad programming practice. In New Flavors, these arguments were
resolved in favor of consistency of contracts, rather than the
increased flexibility of different contracts for different methods,
but not everyone was happy.
I think it is possible to know that a method is coming from a particular
part of the class lattice (without knowing the exact method) and hence
know the local contract. Consistency of generic contract is only in the
required argument set.
To take care of GFD#2, I propose that we allow the generic to specify
optionals that it fills in. The contract between the generic and the
methods is to always supply these required method arguments. I claim it
should not be part of the contract between the generic and the method to
provide that information. I propose a lambda list keyword option
&generic-optional in the generic function. Optional argument
specifications after this provide only argument names and default value
forms, but cannot have a supplied-p variable.
For example:
(defgeneric draw (thing &generic-optional (place *draw-window*))
"Draw thing on place.")
(defmethod draw ((thing line) (place raster-display)) ...)
(defmethod draw ((thing line) (place vector-display)) ...)
Methods must have required arguments where generic-optionals are
provided. Optionals in methods cannot be discriminated on.
Case 3 "move" is outlawed by this proposal, because the number of
required arguments differ.
∂21-Sep-86 1925 Bobrow.pa@Xerox.COM Class Precedence List
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 21 Sep 86 19:25:29 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 SEP 86 19:19:28 PDT
Date: 21 Sep 86 19:19 PDT
Sender: Bobrow.pa@Xerox.COM
Subject: Class Precedence List
To: CommonLoopsCore↑.pa@Xerox.COM
cc: Bobrow.pa@Xerox.COM
From: Danny Bobrow <Bobrow.pa@Xerox.COM>, Kahn.pa@Xerox.COM
Message-ID: <860921-191928-1425@Xerox>
A recursive rule that computes class precedence lists locally.
1) A class c1 cannot be given any super that has c1 in its
class-precedence list.
2) If c1 has one superclass c2, then the class precedence list of c1 is
(cons c1 (c-p-l c2))
3) If c1 has two superclasses, c2 and c3, then use
(cons c1 (merge-pls (c-p-l c2) (c-p-l c3))
where (merge-pls first second)
takes the prefix of first until it finds an element in common with
second.
If there is none, then use all of first. Follow by the prefix of second
up to the common element. If this has any element in common with the
rest of first, signal an error. Insert the common element. Repeat
until first is empty, then append the rest of second.
4) If there are more than 2, then merge the pairs in an associative
manner
The claim is that this algorithm produces lists that obey all of Moon's
rules, is local and one pass.
"Proof"
A class with no super obeys Moon's rules
Proceed by induction.
Clearly (1) Each class precedes it own supers
(2) Local ordering is preserved, since no ordering in the individual
lists is changed by the merge. And the first element of each sublist
(the local supers) have their order preserved.
(3) Duplicate elimination always puts things as early as they can go.
Several minutes thought has shown no problem with this.???
danny and ken
∂21-Sep-86 2233 MASINTER.PA@Xerox.COM initial class lattice
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 21 Sep 86 22:33:48 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 SEP 86 22:24:30 PDT
From: MASINTER.PA@Xerox.COM
Date: 21 Sep 86 22:24:10 PDT
Subject: initial class lattice
To: commonloopscore↑.PA@Xerox.COM
Message-ID: <860921-222430-1479@Xerox>
I had some questions about the initial class lattice for Common Lisp
types.
First, since Common Lisp doesn't require "compiled-function" or
"function" to be first-class, they can't be classes in the initial
hierarchy. (Recall that a compiled function is allowed to be a vector,
for example.)
Second, while "standard-char" is well defined, I don't think it should
be a class; I imagine it would otherwise be difficult to make (class-of
#\a) return something other than (class-of #\page).
Third, I don't think that bit, fixnum and bignum should be defined to be
part of the required class lattice, because they correspond conceptually
to "range" types.
Finally, for those items that have multiple superclasses, we need to
either defince an order or else remove one of the superclasses.
I like having "list" as a class, but the precidence for NIL needs to be
defined. I'd say that NIL was a symbol first and a list second, on the
basis that "list" is an abstraction but "symbol" is quite concrete, and,
at least when I write 'em, I tend to put the concrete classes before the
abstract ones.
As for simple-vector, simple-bit-vector, simple-string, my inclination
is that "simple" isn't a particularly interesting dimension to
discriminate on; removing "simple-array" would do most of the cleanup,
and saying that a "vector" is first an array and secondly a sequence
would finish it off.
(I'm typing this at a stupid dial-in mailer which doesn't allow me to
edit, so I'll add as an afterthought):
On further examination, there are no requirements that stream,
hash-table, readtable, package, pathname or random-state be distinct
from other types (p 33), and my belief is that these cannot then be
required to be "first class" classes, in that (class-of (make-hash-table
...)) might return the same as (class-of (make-array ...)) for suitable
arguments.
Perhaps this can be stated in the subjunctive, e.g. "if these are
distinct types in your Common Lisp implementation, they'll probably be
distinct classes in any implementation of this spec".
∂22-Sep-86 0123 MASINTER.PA@Xerox.COM another name for "run-super"
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Sep 86 01:22:58 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 SEP 86 01:22:36 PDT
From: MASINTER.PA@Xerox.COM
Date: 22 Sep 86 1:22:20 PDT
Subject: another name for "run-super"
To: commonloopscore↑.PA@Xerox.COM
Message-ID: <860922-012236-1523@Xerox>
names matter, I guess.
There's no "run" in Common Lisp, and no "super" in CommonLoops. How about
call-next-method. (Or, if you want, apply-next-method).
∂22-Sep-86 0829 Owners-commonloopscore↑.PA@Xerox.COM another name for "run-super"
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Sep 86 08:29:42 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 22 SEP 86 08:19:44 PDT
Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: commonloopscore↑.PA
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
Xerox.COM ; 22 SEP 86 08:19:13 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 109619; Mon
22-Sep-86 11:17:24 EDT
Date: Mon, 22 Sep 86 11:16 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: another name for "run-super"
To: MASINTER.PA@Xerox.COM
cc: commonloopscore↑.PA@Xerox.COM
In-Reply-To: <860922-012236-1523@Xerox>
Message-ID: <860922111626.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 22 Sep 86 1:22:20 PDT
From: MASINTER.PA@Xerox.COM
call-next-method. (Or, if you want, apply-next-method).
Call-next-method is a better suggestion than mine: next-method.
If we were to add an extension to allow different arguments to be
substituted when calling the next method, both call-next-method
and apply-next-method would be necessary (one is like funcall,
the other is like apply), so I think these are good names.
∂22-Sep-86 0916 Owners-commonloopscore↑.PA@Xerox.COM initial class lattice
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Sep 86 09:15:20 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 22 SEP 86 09:08:43 PDT
Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: commonloopscore↑.PA
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
Xerox.COM ; 22 SEP 86 09:04:06 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 109670; Mon
22-Sep-86 12:01:47 EDT
Date: Mon, 22 Sep 86 12:00 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: initial class lattice
To: commonloopscore↑.PA@Xerox.COM
In-Reply-To: <860921-222430-1479@Xerox>
Message-ID: <860922120053.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 21 Sep 86 22:24:10 PDT
From: MASINTER.PA@Xerox.COM
I had some questions about the initial class lattice for Common Lisp
types.
I've been thinking about this also, but wasn't quite ready to mail out
my complete list yet. I'll give some comments now, though. In most
cases I agree with you.
First, since Common Lisp doesn't require "compiled-function" or
"function" to be first-class, they can't be classes in the initial
hierarchy. (Recall that a compiled function is allowed to be a vector,
for example.)
COMPILED-FUNCTION is allowed to inherit from VECTOR [does it say this in
CLtL someplace?], but it's still meaningful to ask "is this object a
compiled-function", so it should be meaningful to define a method that
applies if one of its arguments is a compiled-function. On the other
hand, the definition of the FUNCTION type (CLtL p.32) is so vague that
even though there is a FUNCTIONP function, I hesitate to say that it
should be meaningful to define a method that applies if one of its
arguments is a function. So I agree with you about FUNCTION, but
disagree on COMPILED-FUNCTION.
It is an interesting point that, although we can identify some classes
for the built-in Common Lisp types, we can't identify all the subclass
relationships among these classes, which in fact are implementation-dependent.
One could say that there are standardized subclass relationships, which
are different from the implementation-dependent subtype relationships,
but I think that approach would be confusing and cause problems. I think
it's better for the subclass relationships to reflect reality, even when
that makes them implementation-dependent. My intuition is that this will
not introduce any new portability problems that were not already present.
Alternatively, these built-in types could be allowed as specifiers in
methods, but not be considered classes. After all, they already do not
participate in the full class protocol. Built-in types are not acceptable
to MAKE-INSTANCE and are not acceptable as superclasses in DEFCLASS.
That way, there wouldn't be any issue of possible inconsistency between
SUBTYPEP and sub-class relationships. On the other hand, this could just
be ducking the issue, since one still must ask what methods are inherited
by a given object.
Perhaps what it comes down to is: what is the CLASS-OF function good for?
Any thoughts on this?
Second, while "standard-char" is well defined, I don't think it should
be a class; I imagine it would otherwise be difficult to make (class-of
#\a) return something other than (class-of #\page).
I agree with you that STANDARD-CHAR shouldn't be a class, i.e. shouldn't
be something that can have methods defined. My reason would be that it
is too specific, that is, it doesn't seem useful to have a different
method for STANDARD-CHAR than for CHARACTER for any generic function I
can think of. Thus I wouldn't allow STANDARD-CHAR until I was allowing
all of the other Common Lisp type-specifiers that are really
predications rather than classes. On the other hand, it would only take
one example of a generic function that had different methods for
STANDARD-CHAR and CHARACTER to change my mind on this one.
I don't see why there would be any special implementation problems in
CLASS-OF, though.
Third, I don't think that bit, fixnum and bignum should be defined to be
part of the required class lattice, because they correspond conceptually
to "range" types.
I agree with you here. BIT is in the same category as STANDARD-CHAR.
KEYWORD and STRING-CHAR are also in this category.
FIXNUM and BIGNUM are implementation characteristics of integers; they
don't change the behavior (given a definition of behavior abstract enough
to rule out performance differences). Thus I don't think it makes sense
for methods to make a distinction between FIXNUM and BIGNUM. This is
different from my reason for excluding BIT.
Finally, for those items that have multiple superclasses, we need to
either define an order or else remove one of the superclasses.
I agree.
I like having "list" as a class, but the precidence for NIL needs to be
defined. I'd say that NIL was a symbol first and a list second, on the
basis that "list" is an abstraction but "symbol" is quite concrete, and,
at least when I write 'em, I tend to put the concrete classes before the
abstract ones.
That was my reasoning also. Converting a partial ordering to a total
ordering for the sake of brevity, I would rank classes in order from
most specific to most general:
RATIONAL FLOAT NUMBER SYMBOL LIST VECTOR ARRAY SEQUENCE
These are all the built-in classes that definitely have subclasses.
As for simple-vector, simple-bit-vector, simple-string, my inclination
is that "simple" isn't a particularly interesting dimension to
discriminate on; removing "simple-array" would do most of the cleanup,
and saying that a "vector" is first an array and secondly a sequence
would finish it off.
I think this is similar to the fixnum/bignum situation. Simpleness of an
array is an implementation characteristic, not a behavior characteristic.
I agree with both of your points here (don't have classes for simple-xxx;
array is more specific than sequence).
On further examination, there are no requirements that stream,
hash-table, readtable, package, pathname or random-state be distinct
from other types (p 33), and my belief is that these cannot then be
required to be "first class" classes, in that (class-of (make-hash-table
...)) might return the same as (class-of (make-array ...)) for suitable
arguments.
Perhaps this can be stated in the subjunctive, e.g. "if these are
distinct types in your Common Lisp implementation, they'll probably be
distinct classes in any implementation of this spec".
The language in CLtL pp.33-5 wasn't written with the concept of
inheritance in mind, it seems. However, there are predicates defined to
test for all of these types, and they are required to be distinct from
each other (third bullet on p.35), so I don't think an implementation
could have them totally indistinguishable from other types. I.e.
(class-of (make-hash-table ...)) might return the same as (class-of
(make-array ...)) for suitable arguments, but not for -all- arguments.
Given this, it just means that (SUBTYPEP 'HASH-TABLE 'ARRAY) is
implementation-dependent, which doesn't seem fatal to the idea of
HASH-TABLE being a class. My thinking was to allow methods to
discriminate on all of the types you mentioned, except STREAM. I
exclude STREAM for the same reason as FUNCTION; its definition is too
vague (but see below).
My reasons for excluding other built-in types listed in CLtL Table 4-1:
ATOM this is (NOT CONS), and we're not doing NOT yet
[see McAllester and Zabih Boolean Classes paper
at OOPSLA for some thoughts on why NOT is hard].
COMMON specification is too vague
NIL no object can be an instance of this type
Another way of looking at these choices is that if there is a MAKE-xxx
function, or something equivalent, I have included the type, but if there
isn't, I have excluded it. Since there aren't separate functions for
making BITs, FIXNUMs, and BIGNUMs, they're excluded. FUNCTION is excluded
because there is no function to make functions, but COMPILED-FUNCTION
is included because COMPILE exists. STREAM is excluded because there
isn't one function to make streams, and in fact many different types
of objects can be streams. This line of reasoning isn't watertight,
but it's a pretty good heuristic.
∂22-Sep-86 1024 Owners-CommonLoopsCore↑.pa@Xerox.COM Class Precedence List
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Sep 86 10:23:52 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 22 SEP 86 09:51:36 PDT
Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.pa
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
Xerox.COM ; 22 SEP 86 09:40:08 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 109702; Mon
22-Sep-86 12:38:18 EDT
Date: Mon, 22 Sep 86 12:37 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Class Precedence List
To: CommonLoopsCore↑.pa@Xerox.COM
In-Reply-To: <860921-191928-1425@Xerox>
Message-ID: <860922123733.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 21 Sep 86 19:19 PDT
From: Danny Bobrow <Bobrow.pa@Xerox.COM>, Kahn.pa@Xerox.COM
A recursive rule that computes class precedence lists locally.
1) A class c1 cannot be given any super that has c1 in its
class-precedence list.
2) If c1 has one superclass c2, then the class precedence list of c1 is
(cons c1 (c-p-l c2))
3) If c1 has two superclasses, c2 and c3, then use
(cons c1 (merge-pls (c-p-l c2) (c-p-l c3))
where (merge-pls first second)
takes the prefix of first until it finds an element in common with
second.
If there is none, then use all of first. Follow by the prefix of second
up to the common element. If this has any element in common with the
rest of first, signal an error. Insert the common element. Repeat
until first is empty, then append the rest of second.
4) If there are more than 2, then merge the pairs in an associative
manner
This requires that the class-precedence-list of every class be available
explicitly. In our implementation we compute and store only the
precedence list of classes that are instantiated, or are going to be
instantiated. For example, in the world I am running right now there
are 2668 classes, of which 1736 (65%) have class-precedence-lists and
932 (35%) don't. Only 643 (24%) of the classes have actually been
instantiated, so an implementation that wasn't as concerned about
preparing things in advance of instantiation would have a higher cost
for precomputing the class-precedence-list of every class. I checked a
world that was booted this morning, rather than a fortnight ago, and
hasn't been used for program development, and the percentages are not
significantly different.
The claim is that this algorithm produces lists that obey all of Moon's
rules, is local and one pass.
"Proof"
A class with no super obeys Moon's rules
Proceed by induction.
Clearly (1) Each class precedes it own supers
(2) Local ordering is preserved, since no ordering in the individual
lists is changed by the merge. And the first element of each sublist
(the local supers) have their order preserved.
(3) Duplicate elimination always puts things as early as they can go.
Several minutes thought has shown no problem with this.???
This algorithm might be okay, but I'm having trouble understanding your
description with enough precision to be sure what it does. I can't be
sure that using the class-precedence-lists of the superclasses does the
same thing as looking directly at the constraints in each class, since
the class-precedence-list is a total ordering, and therefore contains
spurious orderings that are not implied by the partial ordering that the
programmer specified.
If you translate your algorithm to Lisp code and send it to me, I'll be
happy to check it against my algorithm, by eye and by running a thousand
test cases that I happen to have lying around. (Unfortunately I don't
have a comprehensive set of test cases that are supposed to signal errors,
but I'll try two or three).
You have the Lisp code for my algorithm, don't you? I think I sent it
to Gregor a long time ago. We are making all of the New Flavors source
code publically available, subject only to the requirement that people
who copy it don't remove our copyright, so if you don't have the code
let me know and I'll send it to you. I can send you just the class
precedence functions through the mail, or with more delay I could send
everything on some medium (maybe I have to have a signed agreement not
to yank off the copyright before I can send everything).
∂22-Sep-86 1025 Bobrow.pa@Xerox.COM Re: Class Precedence List
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Sep 86 10:24:12 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 SEP 86 10:12:03 PDT
Date: 22 Sep 86 10:11 PDT
Sender: Bobrow.pa@Xerox.COM
Subject: Re: Class Precedence List
In-reply-to: Danny Bobrow <Bobrow.pa>, Kahn's message of 21 Sep 86 19:19
PDT
To: Bobrow.pa@Xerox.COM, Kahn.pa@Xerox.COM
cc: CommonLoopsCore↑.pa@Xerox.COM
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Message-ID: <860922-101203-1764@Xerox>
A recursive rule that computes class precedence lists locally.
1) A class c1 cannot be given any super that has c1 in its
class-precedence list.
2) If c1 has one superclass c2, then the class precedence list
of c1 is (cons c1 (c-p-l c2))
3) If c1 has two superclasses, c2 and c3, then use (cons c1
(merge-pls (c-p-l c2) (c-p-l c3))
where (merge-pls first second) takes the prefix of first until
it finds an element in common with second. If there is none, then
use all of first. Follow by the prefix of second up to the common
element. If this has any element in common with the rest of first,
signal an error. Insert the common element. Repeat until first is
empty, then append the rest of second.
4) If there are more than 2, then merge the pairs in an
associative manner
The claim is that this algorithm produces lists that obey all
of Moon's rules, is local and one pass.
Some more thought has shown that although this is true, it gives an
error in cases where Moon's multipass algorithm is claimed to work.
Consider classes with supers
class Supers Precedence Lists
F1 B C F1 B C Object
F2 A C F2 A C Object
F3 A B F3 A B Object
G F1 F2 G F1 B F2 A C Object
(The legal Moon list computed by Moon's algortihm and ours)
H G F3 Error!!! by our algorithm
But a legal Moon precedence list for H is
H G F1 F2 F3 A B C Object
Notice that the order of A and B are in opposite orders in precedence
lists for G and H. Is this freedom desirable? If not, then our
algorithm is good. If so, then ???
-- danny and ken
∂22-Sep-86 1130 Owners-CommonLoopsCore↑.pa@Xerox.COM Generic Function Objects
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Sep 86 11:30:37 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 22 SEP 86 11:00:26 PDT
Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.pa
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
Xerox.COM ; 22 SEP 86 10:59:49 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 109808; Mon
22-Sep-86 13:58:00 EDT
Date: Mon, 22 Sep 86 13:56 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Generic Function Objects
To: CommonLoopsCore↑.pa@Xerox.COM
In-Reply-To: <860921-153930-1345@Xerox>
Message-ID: <860922135659.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 21 Sep 86 15:39 PDT
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
In the existing CommonLoops papers and code, there is an object called
the discriminator and piece of code called the discriminating function.
The discriminating function was stored inside the discriminator, and
when the discriminator was "named", was also stored in the
symbol-function cell of the symbol which named the discriminator. The
discriminating-function was the thing you funcalled, the discriminator
was the thing that you passed to add-method.
A potentially better design combines the discriminator and the
discriminating function into a single, closure-like, object called the
generic function. The generic function is funcallable; funcalling it
causes method lookup to happen. Accessors which used to work on the
discriminator work directly on the generic function. In particular,
generic-function-methods returns a list of all the methods defined on a
generic function.
Generic functions are mutable, and are side-effected by add-method and
remove-method. An alternative proposal makes them immutable, add-method
and remove-method return new generic-functions, see Masinter's message
of 21-Sep-86 12:26:49 PDT.
We spent a fair amount of time discussing the implementation
implications of this. We believe that this does not cause serious
implementation problems. At least the mutable case can even be
implemented fairly efficiently in PCL.
This new scheme has not yet been discussed on this list though. This
message is intended to spark that discussion.
Well, Dick brought this up on 29 August, and I discussed it on 3 Sep
(see Message-ID: <860903155437.5.MOON@EUPHRATES.SCRC.Symbolics.COM>),
and Dick replied with some vague answers ("I think we have a cleaner design than
what you suggest."), (see Message-ID: <860903-150632-1329@Xerox>),
but it seems to have been dropped after that.
I still believe what I said back then:
The primary reason for keeping them separate is to gain the freedom
to perform implementation-dependent optimizations of the time-critical
operation of calling a generic function. In our implementation we could
rather easily make the function definition of the name of a generic
function be an acceptable argument to the other operations on generic
functions, as a synonym for the generic function meta-object itself,
but I'm not sure if all implementations could do this, since Common Lisp
defines very little of the characteristics of a compiled-function as an
object.
∂22-Sep-86 1132 Gregor.pa@Xerox.COM Re: Class Precedence List
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Sep 86 11:31:51 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 SEP 86 11:31:13 PDT
Date: 22 Sep 86 11:19 PDT
Sender: Gregor.pa@Xerox.COM
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
Subject: Re: Class Precedence List
In-reply-to: Danny Bobrow <Bobrow.pa>, Kahn's message of 21 Sep 86 19:19
PDT
To: Bobrow.pa@Xerox.COM, Kahn.pa@Xerox.COM
cc: CommonLoopsCore↑.pa@Xerox.COM
Message-ID: <860922-113113-1887@Xerox>
One problem with this algorithm is that compute-class-precedence-list is
required to be a function of the local-supers tree. It is specifically
not allowed to just snarf the CPL of a class that it comes across, but
rather must recompute it. I have not yet figured out what the
implications are, in this particular case, of violating this rule.
Another problem with this algortihm is that it doesn't, at least from
the explanation you give, seem any easier to explain than Moon's rules.
∂22-Sep-86 1300 Gregor.pa@Xerox.COM Re: Generic Function Objects
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Sep 86 13:00:16 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 SEP 86 11:33:54 PDT
Date: 22 Sep 86 11:27 PDT
Sender: Gregor.pa@Xerox.COM
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
Subject: Re: Generic Function Objects
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Mon, 22 Sep 86 13:56 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CommonLoopsCore↑.pa@Xerox.COM
Message-ID: <860922-113354-189@Xerox>
It is my belief (actually, I am pretty sure Danny and Dick agree), that
this reduces to the problem of fast funcall for compiled, indefinite
extent lexical closure fast. We assumed that most Common Lisps had
tackled that problem, and could re-use the same technology.
∂22-Sep-86 1410 masinter.pa@Xerox.COM Re: initial class lattice
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Sep 86 14:05:20 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 SEP 86 13:48:03 PDT
Date: 22 Sep 86 13:42 PDT
From: masinter.pa@Xerox.COM
Subject: Re: initial class lattice
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Mon, 22 Sep 86 12:00 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: commonloopscore↑.PA@Xerox.COM
Message-ID: <860922-134803-1141@Xerox>
The objective is to allow class-of to be fast even in implementations
where some other predicates (e.g., compiled-function-p) are slow. Any
meta-operation needs to first get the class so that it can participate
in discrimination, and meta-operations are performance critical; e.g.,
there are a number of operations (e.g., get-slot) which are defined in
terms of the meta-class rather than the class, and which might compile
inline as a method-invocation on class-of. For that reason, the leaves
of the initial class hierarchy should be restricted to be those items
which are known to be immediately computable from the object and from
its type tags.
For newly defined classes, we can insure that class-of can be executed
quickly. However, for the built-in classes, we need to integrate over
the range of Lisp implementations so as not to invalidate what would
otherwise be a good implementation technique (read: hack). If
compiled-function is allowed to inherit from vector, then it must be
that for any vector, (class-of ...) needs to ask compiled-function-p,
which could be relatively expensive. It is much preferable to "leave it
out".... certainly it can be added in for those that keep it separate.
There were reasons before to not make requirements on the implementation
of compiled functions, and they remain.
It is unacceptable to define arbitrary subclass relationships, because
the type predicates would disagree with the class predicates. (vectorp
x) but (class-of x) isn't a subclass of vector.
The major problem with "type specifiers" which are not class in
discrimination is avoiding ambiguity and insuring portability.
- - - - - - -
Another thing CLASS-OF is good for is a more principled approach to what
type-of attempts and fails at. TYPE-OF is hopelessly underspecified,
and, as such, is not useful in portable code.
CLASS-OF, however, is reasonably well specified (once the bugs in the
initial class lattice are worked out), and then an implementation
(defun type-of (x) (class-name (class-of x)))
would be a reasonable way of "cleaning up" what is otherwise a mess.
CLASS-OF allows meta-class discrimination, e.g., (mapcar #'(lambda
(slot) (get-slot x slot) (class-slots (class-of x)))).
- - - - - - - -
We should be explicit about allowable extensions to the class lattice
(e.g., for all vectors, it is only required that class-of return a
subclass of class vector, and it is possible to add intermediate classes
as well).
∂22-Sep-86 1410 Owners-CommonLoopsCore↑.pa@Xerox.COM Re: Class Precedence List
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Sep 86 14:05:27 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 22 SEP 86 14:02:42 PDT
Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.pa
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
Xerox.COM ; 22 SEP 86 13:39:46 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 110024; Mon
22-Sep-86 16:37:51 EDT
Date: Mon, 22 Sep 86 16:36 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Class Precedence List
To: CommonLoopsCore↑.pa@Xerox.COM
In-Reply-To: <860922-101203-1764@Xerox>
Message-ID: <860922163653.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 22 Sep 86 10:11 PDT
From: Danny Bobrow <Bobrow.pa@Xerox.COM>, Ken Kahn
....Notice that the order of A and B are in opposite orders in precedence
lists for G and H. Is this freedom desirable?
I don't see why not. It seems to me that if there is no constraint on
the ordering of those classes, you are not doing the user a favor by
complaining that H is illegal when it doesn't violate any local ordering
constraints. You're just harrassing the user.
I wrote a little program that searched the world on my machine for pairs
of flavors that don't always appear in the same order. It found 1830
pairs. I think this is some sort of evidence that this freedom is, in
fact, desirable. I looked at a few pairs and they generally seem to be
flavors whose ordering doesn't matter because they have orthogonal
behavior (i.e. no methods in common).
If not, then our
algorithm is good. If so, then ???
I think this must be an example of the problem I suspected in my
previous message where your algorithm, by using a total ordering as a
standin for a partial ordering, generates spurious ordering constraints
which then get you into trouble. What are the reasons for not using the
partial ordering instead?
∂22-Sep-86 1510 Owners-CommonLoopsCore↑.pa@Xerox.COM Re: Generic Function Objects
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Sep 86 15:10:37 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 22 SEP 86 14:06:06 PDT
Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.pa
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
Xerox.COM ; 22 SEP 86 13:56:16 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 110053; Mon
22-Sep-86 16:53:37 EDT
Date: Mon, 22 Sep 86 16:52 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Generic Function Objects
To: CommonLoopsCore↑.pa@Xerox.COM
In-Reply-To: <860922-113354-189@Xerox>
Message-ID: <860922165254.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 22 Sep 86 11:27 PDT
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
It is my belief (actually, I am pretty sure Danny and Dick agree), that
this reduces to the problem of fast funcall for compiled, indefinite
extent lexical closure fast. We assumed that most Common Lisps had
tackled that problem, and could re-use the same technology.
Personally I think it's important for the wide acceptance of this standard
for it to avoid features that could cause unnecessary efficiency problems
on some implementations. No matter how fast funcalling a closure is, it's
going to be a little slower than calling something that isn't a closure.
If every microsecond counts, this could be a problem.
As I said, Symbolics has no problem with this, but I think that before
putting something into the standard that might cause problems for some
implementations we should either get wider input so we can be sure that
it won't cause problems, or we should reexamine the benefits of putting
it into the standard to make sure the benefits outweigh the costs.
No one has ever answered my question of what are the benefits, unless I
missed the answer. As far as I can tell, the sole benefit is that you
can say #'FOO instead of (GENERIC-FUNCTION-NAMED 'FOO). Perhaps there
is something else that I am missing. So far no one has ever answered
this question.
∂22-Sep-86 1511 masinter.pa@Xerox.COM Re: Syntax of DEFCLASS
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Sep 86 15:10:53 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 SEP 86 14:44:21 PDT
Date: 22 Sep 86 14:30 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Syntax of DEFCLASS
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Sun, 21 Sep 86 18:20 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
line-fold: no
cc: CommonLoopsCore↑.pa@Xerox.COM
Message-ID: <860922-144421-1211@Xerox>
Many of your arguments are historical ("The real problem with defstruct is that it was designed nine years ago...") I thought I would check the historical record. I've scanned the Common Lisp mail for the last 4 years and found only the following. The lack of any proposals to change defstruct, while there've been proposals galore to do lots of violence, leads me to believe that the syntax, while not the "best", is certainly adequate. And, now that there are thousands of users of Common Lisp and at least 8 textbooks and numerous courses and etc, I think we're best off living with it. I don't think a proposal to change it will fly.
Date: 1 October 1982 04:06-EDT
From: Alan Bawden <ALAN at MIT-MC>
Subject: DEFSTRUCT options syntax
To: Common-Lisp at SU-AI
From the last meeting:
17. Can we standardize on keywords always being used as
name-value pairs? The worst current deviants are
WITH-OPEN-FILE and DEFSTRUCT options.
Yes. The Lisp Machine LISP group will make a
proposal soon for OPEN, WITH-OPEN-FILE, and
DEFSTRUCT.
While everyone agrees that OPEN and WITH-OPEN-FILE should be fixed (and they already have been fixed on the Lisp Machine), the case for DEFSTRUCT is not as clear. In my opinion the change is gratuitous since the options list in a defstruct is NOT a function call. Furthermore it is more than a non-trivial incompatible change since each option has to be re-thought in light of the fact that it can now be given only one argument rather than any number. (Note that the :CONSTRUCTOR and :INCLUDE options take advantage of this multiple-argument ability.)
I asked Moon and DLW if they agreed with me on this subject. Moon replied:
Date: Thursday, 30 September 1982 00:44-EDT
From: MOON at SCRC-TENEX
To: DLW at SCRC-TENEX
cc: Alan
Re: gratuitous change to defstruct syntax.
I've changed my mind about this since August, and am now in agreement with
Alan. Partly this was caused by thinking about what it would mean to
change DEFFLAVOR to use alternating keywords and values; it seems very
clear that it would make it much worse. Thinking about this more made me
decide that some special forms have syntax that looks something like a
function call, but many are totally unrelated to function calls and trying
to wedge them into the same mold is just confused (and confusing).
Certainly the way OPEN used to be was wrong, and fixing it was a big win.
But I think DEFSTRUCT should stay with "option" or "(option args...)"
syntax, as should DEFFLAVOR, DEFSYSTEM, DEFSITE, and who knows what else.
It probably is not a coincidence that these are all "defining" forms.
DLW is also in agreement with me on this. How about it folks, can we keep DEFSTRUCT parsing its options the way it is now?
02-Oct-82 0939 Guy.Steele at CMU-10A keyword pairs and DEFSTRUCT
Date: 2 October 1982 1240-EDT (Saturday)
From: Guy.Steele at CMU-10A
To: common-lisp at SU-AI
Subject: keyword pairs and DEFSTRUCT
I am in sympathy with leaving DEFSTRUCT as is. Indeed, there may be something odd about DEF-forms. OPEN was the biggest thorn, to my mind.
13-Oct-82 1309 STEELE at CMU-20C Ballot results
Date: 13 Oct 1982 1608-EDT
From: STEELE at CMU-20C
Subject: Ballot results
To: common-lisp at SU-AI
...
27. Shall DEFMACRO, DEFSTRUCT, and other defining forms also be allowed to take documentation strings as possible and appropriate?
(y) yes (n) no
Issue 27: *** Y *** Hedrick: Y Wholey: Y Fahlman: Y Weinreb: Y Killian: Y Zubkoff: Y Moon: Y van Roggen: Y Masinter: Y RMS: Y Dyer: Y Bawden: Y Feinberg: Y Ginder: Y Burke et al.: Y Brooks: Y Gabriel: Y DECLISP: Y Steele: Y Dill: X Scherlis: Y Pitman: Y Anderson: Y
∂22-Sep-86 1628 Owners-commonloopscore↑.PA@Xerox.COM Re: initial class lattice
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Sep 86 16:28:14 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 22 SEP 86 15:32:37 PDT
Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: commonloopscore↑.PA
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
Xerox.COM ; 22 SEP 86 15:31:30 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 110144; Mon
22-Sep-86 18:03:58 EDT
Date: Mon, 22 Sep 86 18:03 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: initial class lattice
To: commonloopscore↑.PA@Xerox.COM
In-Reply-To: <860922-134803-1141@Xerox>
Message-ID: <860922180312.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 22 Sep 86 13:42 PDT
From: masinter.pa@Xerox.COM
The objective is to allow class-of to be fast even in implementations
where some other predicates (e.g., compiled-function-p) are slow....
For that reason, the leaves
of the initial class hierarchy should be restricted to be those items
which are known to be immediately computable from the object and from
its type tags.
....
Another thing CLASS-OF is good for is a more principled approach to what
type-of attempts and fails at. TYPE-OF is hopelessly underspecified,
and, as such, is not useful in portable code.
CLASS-OF, however, is reasonably well specified (once the bugs in the
initial class lattice are worked out), and then an implementation
(defun type-of (x) (class-name (class-of x)))
would be a reasonable way of "cleaning up" what is otherwise a mess.
So TYPE-OF a compiled function would be VECTOR. Sorry, I can't agree
that this constitutes cleaning up the mess! This is independent of the
other issues in your message and shouldn't be allowed to cast doubt
on them.
∂22-Sep-86 1757 Owners-CommonLoopsCore↑.pa@Xerox.COM default optional arguments to a generic function
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Sep 86 17:57:38 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 22 SEP 86 17:50:04 PDT
Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.pa
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
Xerox.COM ; 22 SEP 86 17:45:29 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 110252; Mon
22-Sep-86 20:37:50 EDT
Date: Mon, 22 Sep 86 20:37 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: default optional arguments to a generic function
To: CommonLoopsCore↑.pa@Xerox.COM
In-Reply-To: <860921-180617-1396@Xerox>
Message-ID: <860922203704.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 21 Sep 86 18:06 PDT
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
The following principles seem to be ones we have agreed to with respect
to generic functions and methods.
1) Methods should be able to take any Common Lisp lambda-list. In
particular the default defmethod must be able to look like a defun.
2) defgeneric should be optional, unless special options are used, such
as :generic-function-class.
3) The contract of the generic function should be true for all methods,
and that contract should be computable from a defmethod form.
Agreed.
This seems to lead to two competing proposals (Gregor says I am
oversimplifying)
Proposal a) The generic function specifies the full argument list, and
all methods must have congruent argument lists. This leads to the
problem of defining congruence (Moon proposed some rules, but as
Masinter pointed out, they had a problem with renaming of variables used
in default value forms). It also leads to redundancy in the methods --
making it difficult to change a default value form in a single place.
However, Gregor favors this scheme as later extendible by removing
restrictions. He would allow methods to take extra keywrod args if
&allow-other-keys appears in the defgeneric.
Proposal b) The generic function specifies only the required arguments,
and methods discriminate only on those arguments. However, methods can
have arbitrary argument list beyond the required arguments. From any
method, the generic contract can be computed. All methods must have the
same number of min-args.
I'm not sure these are the only possible proposals. However, proposal
(a) certainly sounds less kludgy as described here. Note that all of
the nonsense with default-value-form congruence is only necessary if use
of optional and keyword arguments for method selection is permitted. At
this point it seems clear to me that there is no way our "sound basis"
goal will allow us to standardize on any form of that at this time,
since anything we come up with is going to be new and untried. I favor
standardizing on a minimal design that does not preclude adding more
features as extensions later, when we understand their implications.
My understanding of the user community's desires is that they would
rather see a smaller standard that is published sooner, rather than a
hairier standard that takes longer to start benefiting them.
This allows cases 1a) and 1b)
Case 1a. "draw-line"
draw-line takes an optional, the width of the line in
device dependent units. Because they are device dependent
units, each individual method would like to default this
argument on its own.
(defmethod draw-line ((dev printer) p1 p2
&optional (width 7)) ...)
(defmethod draw-line ((dev window) p1 p2
&optional (width 1)) ...)
Case 1b.
Within case 1, some methods may want to take an extra
argument. Also see case 3 which is similar.
(defmethod draw-line ((d gray-display) p1 p2
&optional (width 3)
(gray *gray1*))
..)
Date: Wed, 17 Sep 86 16:15 EDT
From: David A. Moon
The problem here is that the generic function doesn't have a
consistent contract. The meaning, or even the existence, of one
argument depends on the class of another argument. I don't see how
a caller of draw-line could operate without knowing the exact
method that was going to be called. From experience I know it's
possible to have all sorts of arguments about whether this is good
or bad programming practice. In New Flavors, these arguments were
resolved in favor of consistency of contracts, rather than the
increased flexibility of different contracts for different methods,
but not everyone was happy.
I think it is possible to know that a method is coming from a particular
part of the class lattice (without knowing the exact method) and hence
know the local contract. Consistency of generic contract is only in the
required argument set.
As I said, it's possible to have all kinds of arguments about this, and
everyone has their own idea of what they would like to see. I don't
even disagree with what you just said. However, the way we are going
around and around on this doesn't sound to me like something that is
ready for standardization. We should tread carefully in this area.
To take care of GFD#2, I propose that we allow the generic to specify
optionals that it fills in. The contract between the generic and the
methods is to always supply these required method arguments. I claim it
should not be part of the contract between the generic and the method to
provide that information.
I can't figure out what the last two sentences, taken as a whole, are saying.
I propose a lambda list keyword option
&generic-optional in the generic function. Optional argument
specifications after this provide only argument names and default value
forms, but cannot have a supplied-p variable.
For example:
(defgeneric draw (thing &generic-optional (place *draw-window*))
"Draw thing on place.")
(defmethod draw ((thing line) (place raster-display)) ...)
(defmethod draw ((thing line) (place vector-display)) ...)
Methods must have required arguments where generic-optionals are
provided. Optionals in methods cannot be discriminated on.
This is fine as a proposal, but I don't think it belongs in a standard.
Next week, or next month, there might be a different idea that seems
better.
Case 3 "move" is outlawed by this proposal, because the number of
required arguments differ.
OK.
∂22-Sep-86 1814 masinter.pa@Xerox.COM Re: default optional arguments to a generic function
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Sep 86 18:14:00 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 SEP 86 18:04:16 PDT
Date: 22 Sep 86 17:58 PDT
From: masinter.pa@Xerox.COM
Subject: Re: default optional arguments to a generic function
To: CommonLoopsCore↑.pa@Xerox.COM
Message-ID: <860922-180416-1453@Xerox>
I think the causes of differences here are twofold: first, whether the
default argument behavior of a function is part of its "external"
contract or something internal, and secondarily, whether language
constructs should be added to enforce contracts.
I do not believe that the argument limits (minimum, maximum, optional,
keyword) are part of the "external contract" of a function. That is,
from the point of view of the caller, there is no difference between a
&rest argument that explicitly checks if too many arguments are supplied
and a &optional argument. While there have been a number of proposals to
add such information to Common Lisp, they have foundered partly on the
objections that such information is not part of the external interface.
If argument behavior is not part of the "external" contract, then of
course methods can simply *differ* on the number of arguments supplied.
Of course, if you get to a method with too many or too few arguments,
you will get an error, just like if you call a function with the wrong
number of arguments.
While this might be "bad programming style" in some cases, it is
legitimate in others (Kahn's arguments about local vs global
consistency).
Environment tools can help detect inconsistent use of arguments in a
method, just as they can help detect a disparity between the number of
arguments supplied and the number expected in static code.
Finally, I object to language constructs in Lisp whose primary function
is to enforce contracts between the caller and callee. While adding the
notion of functional interfaces to Lisp is an interesting research
topic, and matching the interface specification to the various
implementations of that interface a useful construct in modular
programming languages, it does not belong attached to the "object
oriented" part of the language.
Perhaps we want a construct:
(define-function-interface name argument-shape values-shape
documentation)
which asserts that "name" will take arguments described by
argument-shape (which includes both extentional and intentional type
descriptions) and returns values described by values-shape, and has the
following documentation string, and then build some environment tools
that allow programs to be compiled in such a manner that any
disagreement between the function-interface and a defintion or use is
signalled by the compiler/checker. This would be an interesting
facility. It sort of looks like DEFGENERIC. But it doesn't belong here.
Larry
∂22-Sep-86 2229 MASINTER.pa@Xerox.COM class-of compiled objects
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Sep 86 22:29:04 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 SEP 86 22:27:08 PDT
From: MASINTER.pa@Xerox.COM
Date: 22 Sep 86 22:26:48 PDT
Subject: class-of compiled objects
To: (moon)
cc: commonloopscore↑.pa@Xerox.COM
Message-ID: <860922-222708-1576@Xerox>
In those implementations where compiled-function is a subtype of vector,
the only alternative would be to allow (class-name (class-of (make-array
...))) to return 'compiled-function for some unspecified arguments to
make-array, even if the results were not intended to be treated as a
compiled function.
∂22-Sep-86 2236 MASINTER.pa@Xerox.COM generic function objects
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Sep 86 22:35:55 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 SEP 86 22:35:07 PDT
From: MASINTER.pa@Xerox.COM
Date: 22 Sep 86 22:34:47 PDT
Subject: generic function objects
To: commonloopscore↑.pa@Xerox.COM
Message-ID: <860922-223507-1578@Xerox>
(For reference, the question is, is installing a generic function done
with
(setf (symbol-function 'foo) (make-generic-function ...))
or with
(setf (symbol-generic-function 'foo) ...)
I've been meditating on "class-named" and came up with "find-class"
instead, in keeping with "find-package". Another alternative would be
"symbol-class" but that is pretty hopeless, and the class isn't a
property of the symbol, the symbol is just a name for the class.
∂23-Sep-86 0859 Owners-commonloopscore↑.pa@Xerox.COM class-of compiled objects
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 23 Sep 86 08:47:15 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 23 SEP 86 08:45:12 PDT
Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: commonloopscore↑.pa@XEROX.ARPA
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
Xerox.COM ; 23 SEP 86 08:44:46 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 110609; Tue
23-Sep-86 11:41:09 EDT
Date: Tue, 23 Sep 86 11:41 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: class-of compiled objects
To: commonloopscore↑.pa@Xerox.COM
In-Reply-To: <860922-222708-1576@Xerox>
Message-ID: <860923114122.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 22 Sep 86 22:26:48 PDT
From: MASINTER.pa@Xerox.COM
In those implementations where compiled-function is a subtype of vector,
the only alternative would be to allow (class-name (class-of (make-array
...))) to return 'compiled-function for some unspecified arguments to
make-array, even if the results were not intended to be treated as a
compiled function.
Sure, but why is that a problem? Surely that object is indistinguishable
from a compiled-function in every other way, unless an intelligent algorithm
checked the machine instructions in it for plausibility as output from the
compiler, so why not make the class structure consistent with the rest of
the implementation in calling it a compiled-function?
∂23-Sep-86 0902 Owners-CommonLoopsCore↑.PA@Xerox.COM Name of RUN-SUPER
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 23 Sep 86 09:02:06 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 23 SEP 86 08:58:55 PDT
Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.PA@XEROX.ARPA
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
Xerox.COM ; 23 SEP 86 08:58:39 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 110635; Tue
23-Sep-86 11:53:08 EDT
Date: Tue, 23 Sep 86 11:53 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Name of RUN-SUPER
To: CommonLoopsCore↑.PA@Xerox.COM
Message-ID: <860923115320.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
[This was sent last Saturday but apparently did not go through.
In resending it I changed the suggestion from NEXT-METHOD to
CALL-NEXT-METHOD.]
There is a problem with the name of RUN-SUPER. With the introduction
of multimethods, it can no longer be said that RUN-SUPER runs the method
of the superclass. It might use the next argument to choose a method,
and in fact get that method from a class much more specific than the class
from which the current method came. Similarly, the introduction of around
methods mean that RUN-SUPER could be running a more specific method, if
the next method is a primary method rather than another around method.
In both cases, RUN-SUPER is running the next method, not necessarily a
method from a superior class.
For these reasons, I feel that a more appropriate name for this
primitive would be CALL-NEXT-METHOD.
∂23-Sep-86 1354 Owners-commonloopscore↑.PA@Xerox.COM Re: initial class lattice
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 23 Sep 86 13:54:05 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 23 SEP 86 13:50:39 PDT
Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: commonloopscore↑.PA@XEROX.ARPA
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
Xerox.COM ; 23 SEP 86 13:50:24 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 111046; Tue
23-Sep-86 16:48:02 EDT
Date: Tue, 23 Sep 86 16:48 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: initial class lattice
To: commonloopscore↑.PA@Xerox.COM
In-Reply-To: <860922-134803-1141@Xerox>
Message-ID: <860923164810.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 22 Sep 86 13:42 PDT
From: masinter.pa@Xerox.COM
The objective is to allow class-of to be fast even in implementations
where some other predicates (e.g., compiled-function-p) are slow. Any
meta-operation needs to first get the class so that it can participate
in discrimination, and meta-operations are performance critical; e.g.,
there are a number of operations (e.g., get-slot) which are defined in
terms of the meta-class rather than the class, and which might compile
inline as a method-invocation on class-of. For that reason, the leaves
of the initial class hierarchy should be restricted to be those items
which are known to be immediately computable from the object and from
its type tags.
It might pay to examine this a little more closely. To continue with
the example of a compiled-function that is also a vector, the time to do
get-slot of a vector doesn't matter, as long as it doesn't slow down the
time to do get-slot of other types of objects. After all, vectors don't
have slots. Are there examples of other operations that are performance
critical for primitive objects and depend on class-of? I can't imagine
any. So the question is really whether the implementor is smart enough
to implement class-of in such a way that the exception cases, where a
complicated test is required to determine the class, don't slow down the
normal case. This seems a low enough level of issue that it shouldn't
be allowed to dictate the semantics of the language.
∂24-Sep-86 2021 Owners-commonloopscore↑.PA@Xerox.COM Re: (change-class x y) => (setf (class-of x) y)?
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 24 Sep 86 20:20:12 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 24 SEP 86 20:17:09 PDT
Return-Path: <DLW@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: commonloopscore↑.PA@XEROX.ARPA
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
Xerox.COM ; 24 SEP 86 20:16:44 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 112892; Wed
24-Sep-86 23:09:39 EDT
Date: Wed, 24 Sep 86 23:14 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: Re: (change-class x y) => (setf (class-of x) y)?
To: Kahn.pa@Xerox.COM
cc: commonloopscore↑.PA@Xerox.COM
In-Reply-To: <860921-171550-1381@Xerox>
Message-ID: <860924231419.9.DLW@CHICOPEE.SCRC.Symbolics.COM>
Line-fold: No
Date: 21 Sep 86 17:15 PDT
From: Ken Kahn <Kahn.pa@Xerox.COM>
I like Larry's suggestion for the same reasons that most people like
SETF -- fewer names to deal with.
Minimizing the number of names does not mean that things are necessarily
clearer, simpler, and/or easier to understand.
SETF is a construct that deals with a concept that we usually call a
"generalized variable". A generalized variable is, conceptually, a
place to put something. Evaluating the generalized variable returns the
contents of the place. Using SETF on the generalized variable stores
something into the place. That's what SETF is basically about, and
that's how you'd explain SETF in a Lisp course.
Within this conceptual framework, (CLASS-OF ...) does not constitute
a "generalized variable".
In this case, you are attempting to minimize the number of names by
overloading one name with two different functions. This does not make
things simpler or easier to learn.
P.S. Consider that it would never make sense to do (PUSH X (CLASS-OF Y)).
P.P.S. Consider that we do not grow a vector by doing (SETF (LENGTH X) 10).
∂24-Sep-86 2037 Owners-commonloopscore↑.PA@Xerox.COM Re: (change-class x y) => (setf (class-of x) y)?
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 24 Sep 86 20:37:04 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 24 SEP 86 20:33:49 PDT
Redistributed: commonloopscore↑.PA@XEROX.ARPA
Received: from Cabernet.ms by ArpaGateway.ms ; 24 SEP 86 20:33:34 PDT
From: masinter.PA@Xerox.COM
Date: 24 Sep 86 20:33:16 PDT
Subject: Re: (change-class x y) => (setf (class-of x) y)?
In-reply-to: DLW@ALDERAAN.SCRC.Symbolics.COM's message of Wed, 24 Sep 86
23:14 EDT, <860924231419.9.DLW@CHICOPEE.SCRC.Symbolics.COM>
To: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
cc: Kahn.pa@Xerox.COM, commonloopscore↑.PA@Xerox.COM
Message-ID: <860924-203349-3799@Xerox>
All other things being equal, fewer odd names are better. Are you
claiming you like "(change-class x y)" better than "(setf (class-of x)
y)"? If not, do you have a better proposal?
P.S. Consider that it never makes sense to do (PUSH X (SYMBOL-FUNCTION
Y)) either.
P.P.S. Consider that we do shrink adjustable arrays by DECFing their
FILL-POINTER.
∂25-Sep-86 0809 Bobrow.pa@Xerox.COM Re: Class Precedence List
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 25 Sep 86 08:08:53 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 25 SEP 86 08:00:01 PDT
Date: 25 Sep 86 07:59 PDT
Sender: Bobrow.pa@Xerox.COM
Subject: Re: Class Precedence List
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Mon, 22 Sep 86 16:36 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CommonLoopsCore↑.pa@Xerox.COM
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Message-ID: <860925-080001-4023@Xerox>
The search I would be interested in is not the one where there are
differences of order only, but ones in which a subclass has the classes
in a different order than a super. This could lead to strangeness for a
user who tests an operation on a superclass, and finds then happening
differently in a subclass.
However, the partial order is probably the best we can do. I have not
yet seen your code. Haven't asked Gregor.
-- danny
∂25-Sep-86 0810 Bobrow.pa@Xerox.COM [Guy Steele <gls@Think.COM>: Syntax of defstruct versus
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 25 Sep 86 08:09:05 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 25 SEP 86 08:02:33 PDT
Date: 25 Sep 86 08:02 PDT
Sender: Bobrow.pa@Xerox.COM
Subject: [Guy Steele <gls@Think.COM>: Syntax of defstruct versus
DEFCLASS]
To: CommonLoopsCore↑.pa@Xerox.COM
cc: Bobrow.pa@Xerox.COM
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Message-ID: <860925-080233-4027@Xerox>
I asked Guy his opinion about this issue.
Here is his response.
From: Guy Steele <gls@Think.COM>
Subject: Syntax of defstruct versus DEFCLASS
To: Bobrow.pa
Cc: gls@AQUINAS.ARPA
In-Reply-To: <860921-160133-1351@Xerox>
Message-Id: <860922161225.1.GLS@DESCARTES.THINK.COM>
Danny,
I haven't seen all of the discussion that led up to this,
of course. Moon's technical criticism of DEFSTRUCT syntax
is well taken for the most part. It has also bothered me
that the option syntax is not like other uses of keywords
in the language (namely keyword-value pairs), and that you
cannot have slot-options without specifying a value.
If DEFCLASS is to solve some of the modularity problems
such as the distinction between implementation access and
client access, then it is sufficiently different that it is
appropriate to make a clean break and design a good syntax.
If the aim is to be a semantically minimal extension of
DEFSTRUCT, then it should also be a syntactically minimal
extension of DEFSTRUCT. (How is that for waffling? I have
no strong absolute feelings about the issue; I can only
express an opinion on how it should be done relative to a
set of goals.)
As for :conc-name, I think that is really stupid. Why not
let there simply be a default way of making names, and the
default can be overridden for each slot with a slot-option?
--Guy
∂25-Sep-86 1229 masinter.pa@Xerox.COM Re: (change-class x y) => (setf (class-of x) y)?
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 25 Sep 86 12:29:28 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 25 SEP 86 11:29:36 PDT
Date: 25 Sep 86 11:21 PDT
From: masinter.pa@Xerox.COM
Subject: Re: (change-class x y) => (setf (class-of x) y)?
In-reply-to: masinter.PA's message of 24-Sep-86 20:33:16 PDT
To: commonloopscore↑.PA@Xerox.COM
Message-ID: <860925-112936-4275@Xerox>
Let me give a less "off-the-cuff" reply:
For those objects whose class is mutable, the "class-of" the object is
as much of a "generalized variable" as many of the other Common Lisp
constructs which are changed using SETF. The general direction has been
to use SETF whenver possible as the principle way in which objects are
modified; few excepts were made in Common Lisp even where tradition
would have chosen different names.
The notion that some objects have a mutable class may seem strange, but
it seems no more or less strange if the operation is called
"set-class-of" or "change-class" or "setf (class-of".
In any case, the name "change-class" is awkward; there is no other
modify-operation in Common Lisp that is called "change", although
"set-class" or "set-class-of" might be reasonable.
∂25-Sep-86 1229 masinter.pa@Xerox.COM Re: initial class lattice
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 25 Sep 86 12:29:36 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 25 SEP 86 12:20:31 PDT
Date: 25 Sep 86 12:12 PDT
From: masinter.pa@Xerox.COM
Subject: Re: initial class lattice
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Tue, 23 Sep 86 16:48 EDT
To: commonloopscore↑.PA@Xerox.COM
Message-ID: <860925-122031-4341@Xerox>
Masinter: The objective is to allow class-of to be fast even in
implementations...
Moon:
It might pay to examine this a little more closely. To continue with
the example of a compiled-function that is also a vector, the time to do
get-slot of a vector doesn't matter, as long as it doesn't slow down the
time to do get-slot of other types of objects. After all, vectors don't
have slots. Are there examples of other operations that are performance
critical for primitive objects and depend on class-of? I can't imagine
any. So the question is really whether the implementor is smart enough
to implement class-of in such a way that the exception cases, where a
complicated test is required to determine the class, don't slow down the
normal case. This seems a low enough level of issue that it shouldn't
be allowed to dictate the semantics of the language.
Masinter:
Your point is well taken. I agree now that the performance issue is not
critical.
However, the issue remains: which types in CLtL are intrinsic and which
are extrinsic? Clearly (satisfies evenp) is an extrinsic type -- it
depends on a view of the data rather than on the data itself. The
current type system is muddy enough that it allows some implementations
to treat compiled-function-p and hash-table-p and read-table-p as if
they were testing extrinsic properties rather than intrinsic ones, and
thus, the types would not correspond directly to classes.
I think this is one of those awful, picky issues that are irrelevant to
the whole proposal but that standards are made of. The tradeoff is
between power (they're classes, which means you can write discriminators
on them) and portability (some implementations might treat
compiled-function as a sublcass of vector, and others not) and the
constraint of not changing drastically the implementation requirements
of the system. Which would you rather give up?
∂25-Sep-86 1358 Owners-CommonLoopsCore↑.pa@Xerox.COM Re: Class Precedence List
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 25 Sep 86 13:57:54 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 25 SEP 86 12:53:27 PDT
Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.pa@XEROX.ARPA
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
Xerox.COM ; 25 SEP 86 12:52:57 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 114016; Thu
25-Sep-86 14:58:46 EDT
Date: Thu, 25 Sep 86 14:58 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Class Precedence List
To: CommonLoopsCore↑.pa@Xerox.COM
In-Reply-To: <860925-080001-4023@Xerox>
Message-ID: <860925145850.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 25 Sep 86 07:59 PDT
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
The search I would be interested in is not the one where there are
differences of order only, but ones in which a subclass has the classes
in a different order than a super. This could lead to strangeness for a
user who tests an operation on a superclass, and finds then happening
differently in a subclass.
That is exactly what the New Flavors ordering rules, as compared with either
breadth-first or depth-first search, are intended to avoid. It might be that
there are cases where they don't avoid this problem, but I'd have to see
a specific example. The proposed extension, which I kind of like but have
neither implemented nor evaluated its effect on real programs, deals more
stringently with this issue by examining all pairs of component classes whose
order is unconstrained and determining whether exchanging them would alter
any inherited methods; if not, their order doesn't matter, because it doesn't
affect behavior. If so, signal an error. This extension would ensure that
no matter which of the possible total orderings consistent with the partial
ordering is chosen, the behavior is the same.
Even though I like this idea (due to KMP originally I believe) I can't
support putting it into a standard, since it hasn't been tried in the
real world.
∂26-Sep-86 0954 Owners-CommonLoopsCore↑.pa@Xerox.COM Re: Class Precedence List
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 26 Sep 86 09:54:11 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 26 SEP 86 09:50:47 PDT
Redistributed: CommonLoopsCore↑.pa
Received: from Cabernet.ms by ArpaGateway.ms ; 26 SEP 86 09:50:28 PDT
Date: 26 Sep 86 09:45 PDT
Sender: Bobrow.pa@Xerox.COM
Subject: Re: Class Precedence List
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Thu, 25 Sep 86 14:58 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CommonLoopsCore↑.pa@Xerox.COM
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Message-ID: <860926-095047-5234@Xerox>
The search I would be interested in is not the one
where there are differences of order only, but ones in which a
subclass has the classes in a different order than a super.
This could lead to strangeness for a user who tests an
operation on a superclass, and finds then happening differently
in a subclass.
That is exactly what the New Flavors ordering rules, as
compared with either breadth-first or depth-first search, are
intended to avoid. It might be that there are cases where they
don't avoid this problem, but I'd have to see a specific example.
What are the class precedence list for the following
classes (flavors)
class Supers
F1 B C
F2 A C
F3 A B
F4 B A
G F1 F2
H G F3
K G F4
In particular, what are the lists for G, H and K.
H and K must have A nd B in opposite orders. Both have G as a super.
G doesn't care but must have some order.
-- danny
∂26-Sep-86 1330 Owners-CommonLoopsCore↑.pa@Xerox.COM Re: Class Precedence List
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 26 Sep 86 13:26:41 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 26 SEP 86 12:39:22 PDT
Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.pa@XEROX.ARPA
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
Xerox.COM ; 26 SEP 86 12:38:48 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 115970; Fri
26-Sep-86 15:27:09 EDT
Date: Fri, 26 Sep 86 15:27 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Class Precedence List
To: CommonLoopsCore↑.pa@Xerox.COM
In-Reply-To: <860926-095028-5231@Xerox>
Message-ID: <860926152702.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 26 Sep 86 09:45 PDT
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
The search I would be interested in is not the one
where there are differences of order only, but ones in which a
subclass has the classes in a different order than a super.
This could lead to strangeness for a user who tests an
operation on a superclass, and finds then happening differently
in a subclass.
That is exactly what the New Flavors ordering rules, as
compared with either breadth-first or depth-first search, are
intended to avoid. It might be that there are cases where they
don't avoid this problem, but I'd have to see a specific example.
What are the class precedence list for the following
classes (flavors)
class Supers Components
F1 B C (F1 B C)
F2 A C (F2 A C)
F3 A B (F3 A B)
F4 B A (F4 B A)
G F1 F2 (G F1 B F2 A C)
H G F3 (H G F1 F2 F3 A B C)
K G F4 (K G F1 F2 F4 B A C)
In particular, what are the lists for G, H and K.
I filled them into your message above, using a program of course.
I see; now I see what you meant by testing an operation on a
superclass and happening differently on a subclass. G is the
superclass and H is the subclass.
H and K must have A and B in opposite orders. Both have G as a super.
G doesn't care but must have some order.
That's right. If the relative ordering of A and B matters, it
should have been declared explicitly, possibly using the
:component-order option (remember, that's one of the defflavor
options whose usefulness you couldn't see). In fact in the very
many real cases where this happens that I enumerated the other
day, the relative ordering of A and B does not matter. In this
particular specific example, the programmer who wrote F3 and F4
seems to have declared explicitly that the relative ordering of
A and B is immaterial.
The proposed extension from (I think) KMP that I mentioned the
other day is intended to provide automatic detection of whether
or not the relative ordering of A and B matters, instead of
making it the responsibility of the programmer to say whether
it matters. My comments on that extension from the other day
still stand.
∂26-Sep-86 1635 Gregor.pa@Xerox.COM missing excl-low file
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 26 Sep 86 16:34:57 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 26 SEP 86 13:43:17 PDT
Date: Fri, 26 Sep 86 13:36 PDT
From: Gregor.pa@Xerox.COM
Subject: missing excl-low file
To: CommonLoops.PA@Xerox.COM
Message-ID: <860926133653.2.GREGOR@AVALON.XEROX-PARC>
Line-fold: no
For some reason, the file excl-low.l was missing from the /pub/pcl
directory on parcvax.xerox.com. That file now exists on that directory
so people who want to use PCL in Franz Common Lisp (ExCL) should have no
problems.
Gregor
-------
∂29-Sep-86 1328 Owners-commonloops.pa@Xerox.COM getting connected
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 Sep 86 13:28:19 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 29 SEP 86 11:25:38 PDT
Return-Path: <DALY@IBM.COM>
Received: from IBM.COM ([192.5.58.7]) by Xerox.COM ; 29 SEP 86 11:15:57
PDT
Date: 29 September 1986, 13:08:34 EDT
From: "Timothy P. Daly" <DALY@ibm.com>
To: commonloops.pa@Xerox.COM
Message-Id: <092986.130835.daly@ibm.com>
Subject: getting connected
Please add my name to the list of people receiving the common loops
discussions:
DALY@IBM.COM
Thanks.
∂29-Sep-86 1816 Hostrop.PA@Xerox.COM {eris}<Lispcore>...
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 Sep 86 18:16:30 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 29 SEP 86 18:02:04 PDT
Date: 29 Sep 86 17:58:55 PDT (Monday)
From: Hostrop.PA@Xerox.COM
Subject: {eris}<Lispcore>...
To: Lispcore↑.pa@Xerox.COM, CommonLoopsCore↑.pa@Xerox.COM,
AISTest↑.x@Xerox.COM
cc: , Hostrop.PA@Xerox.COM
Reply-To: Hostrop.PA@Xerox.COM
Message-ID: <860929-180204-1109@Xerox>
...has but 3664 pgs left - Those of you writing to this directory are
encouraged to pare out obsolete versions wherever it makes sense. Your
cooperation is greatly appreciated by all patrons of {eris}<Lispcore>.
∂30-Sep-86 1701 Owners-CommonLoops.PA@Xerox.COM Anybody know how objects are represented in PCL?
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 30 Sep 86 17:00:59 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 30 SEP 86 16:53:49 PDT
Return-Path: <luis@ingres.Berkeley.EDU>
Received: from ingres.Berkeley.EDU ([128.32.156.105]) by Xerox.COM ; 30
SEP 86 16:48:55 PDT
Received: by ingres.Berkeley.EDU (5.53/1.14)
id AA00872; Tue, 30 Sep 86 16:23:54 PDT
Date: Tue, 30 Sep 86 16:23:54 PDT
From: luis@ingres.Berkeley.EDU (Luis Miguel)
Message-Id: <8609302323.AA00872@ingres.Berkeley.EDU>
To: CommonLoops.PA@Xerox.COM
Subject: Anybody know how objects are represented in PCL?
Is there an "object table" of some kind? (like the class
hash table).
What we want to do is to be able to "swap" objects in and out
of the system as they are needed (to an object database), and need to
know what the appropriate conversions need to be.
Luis Miguel
luis@ingres.Berkeley.EDU